Re: [PATCH 1/3] improve reliability of fixup_pack_header_footer()

[Nicolas Pitre <nico@cam.org>]

On Fri, 29 Aug 2008, Shawn O. Pearce wrote:

> Oh, yea, that makes sense.  It still seems like playing with fire.
> 
> I'd rather the caller pass in the proper offset than rely on it
> being the current position of the fd.  Especially if the caller
> does actually have it available.
> 
> If you change anything, I'd like to see this lseek(SEEK_CUR) go away.

Done.  I struggled a bit since it simply didn't work initially -- see 
the first patch in the updated series.

> > And another thing I had in store (but for which you _again_ beat me to :-) )
> > is to realign data reads onto filesystem blocks.
> 
> That _really_ made the JGit code ugly.  But I think its worth it.

See my version.  I think it is reasonably clear.

> I also want to try and buffer the whole object appending we do
> during fixThinPack(), as right now we write the object header in
> one write and then compressed data bursts in the others.  Moving it
> to at least write a full 4k at a time should remove about 2 write
> calls per object.

Yep.  In the C git case, moving to sha1write() added that buffering 
for free.


Nicolas