Re: Performance issue: initial git clone causes massive repack

> On Tue, 14 Apr 2009, Johannes Schindelin wrote:
> 
> > IMO the best we could do under these circumstances [unreliable 
> > network] is to use fsck --lost-found to find those commits which have 
> > a complete history (i.e. no "broken links") -- this probably needs to 
> > be implemented as a special mode of --lost-found -- and store them in 
> > a temporary to-be-removed namespace, say 
> > refs/heads/incomplete-refs/$number, which will be sent to the server 
> > when fetching the next time.  (Might need some iterations to get 
> > everything, though.)
> 
> Well, although this might seem a good idea, this would help only in 
> those cases where there is at least one complete revision available, 
> i.e. no delta needed. This is usually true for the top commit after a 
> repack which objects are all stored at the front of the pack and serve 
> as base objects for deltas from subsequent (older) commits.  Thing is, 
> that first revision is likely to occupy a significant portion of the 
> whole pack, like no less than the size of the equivalent .tar.gz for the 
> content of that commit.  To see what this represents, just try a shallow 
> clone with depth=1.  For the Linux kernel, this is more than 80MB while 
> the whole repo is in the 200MB range.  So if your connection isn't 
> reliable enough to transfer at least that amount then you're screwed 
> anyway.