Re: [PATCH 4/8] git-repack --max-pack-size: add fixup_header_footer()

From: Nicolas Pitre <nico@cam.org>
Date: Apr 9, 2007, 18:30 UTC
Message-ID: <alpine.LFD.0.98.0704091404530.28181@xanadu.home>
In-Reply-To: <20070409173858.GT5436@spearce.org>

On Mon, 9 Apr 2007, Shawn O. Pearce wrote:

Show 8 quoted lines

> Nicolas Pitre <nico@cam.org> wrote:
> > I think another file with common pack writing functions could be 
> > created.  Pack index writing is another item that is currently 
> > duplicated in pack-objects and index-pack for example.
> 
> I agree entirely.  And I'd like to see that refactoring occur
> before this series, or as part of it.  At least for the nr_objects
> correction routine.

That's easy enough for the nr_objects correction case.

The next obvious candidate would be index generation, but I'd wait a bit for all features in progress to be merged and stabilize first.

Show 8 quoted lines

> For example, writing objects to a packfile: we have 3
> implementations.  fast-import.c doesn't use sha1write_compressed
> because that was a waste of time to compute the SHA_CTX when we
> know we have to go back and fixup nr_objects.  It also doesn't use
> it because fast-import.c's pack-splitting logic is based on the
> final object size, not the starting offset.  It does the deflate
> itself, decides if the end of the object will overflow, and if so,
> jumps to a new packfile.

I'd be really tempted to create a pack v4 which only change is to still have the pack header at the beginning of the pack like we do today, but include the header in the pack SHA1 computation at the end of the stream only. This way the pack SHA1 could be computed as the pack is generated, and the header fixed up without having to read the entire pack back. I think it was Geert Bosch who proposed this and it makes tons of sense IMHO.

Nicolas