Re: [PATCH] Skip writing out sha1 files for objects in packed git.

quoted

quoted

quoted

quoted

"LT" == Linus Torvalds [off-list ref] writes:

LT> If we want to expand a packed file and really write the objects to the 
LT> .git/objects directories, we should just not have that packed file in the 
LT> .git/objects/pack directory.

What I was aiming for was this:

 (1) Introduce an interface to sha1_file.c that lets you say
     "use this file as one of the packs, although it is not
     under .git/objects/pack";

 (2) Introduce another interface to sha1_file.c that lets you
     enumerate the index entries for a given pack file.

 (3) Remove the unpacking logic from unpack-object.c; instead
     call the above interfaces to register the pack and
     enumerate entries, and call read_sha1_file() followed by
     write_sha1_file() with do_expand repeatedly.

However, the infrastructure (1) and (2) may end up being a
special case only to support unpack-object (and removing the
code duplication for unpacking), in which case what you suggest
would make more sense.

LT> And if we have a pack-file in .git/objects/ that already has
LT> the object, that may not be the _same_ pack-file that we're
LT> expanding at all, so if that pack file already has the
LT> object, then not writing it out is actually the right thing
LT> to do.

This I have to think about a bit.

On Mon, 27 Jun 2005, Junio C Hamano wrote:

LT> And if we have a pack-file in .git/objects/ that already has
LT> the object, that may not be the _same_ pack-file that we're
LT> expanding at all, so if that pack file already has the
LT> object, then not writing it out is actually the right thing
LT> to do.

This I have to think about a bit.

The most trivial example is doing a "git pull" of a small pack-file 
update.

We probably don't want to leave it around as a pack-file (we'll re-pack 
everything at some later date, but we also don't want to expand the stuff 
we already have in our _real_ pack-file).

		Linus