Re: Performance issue: initial git clone causes massive repack

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 23 Apr 2009, Sam Vilain wrote:

> Nicolas Pitre wrote:
> >> Now that the GSoC projects have been announced I can give you the good
> >> news that one of our two projects is to optimise this stage in
> >> git-daemon; I'm hoping we can get it down to being almost as cheap as
> >> the workaround you described in your post. I'll certainly be using your
> >> repository as a test case :-)
> >
> > Please keep me in the loop as much as possible. I'd prefer we're not in
> > disagreement over the implementation only after final patches are posted
> > to the list.
> 
> Thanks Nico, given your close working knowledge of the pack-objects
> code this will be very much appreciated. Perhaps you can first help
> out by telling me what you have to say about moving object enumeration
> from upload-pack to pack-objects?

It is like a 25-line patch or so.  I did it once, although the shalow 
clone support was missing from it.  And somehow I managed to lose the 
patch while doing some reshuffling of unrelated bigger changes.

Basically, you can pass the revision arguments to pack-objects directly 
instead of passing them to rev-list and piping rev-list's output to 
pack-objects.

Nicolas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]