Re: git clone: very long "resolving deltas" phase

[Nicolas Pitre <nico@fluxnic.net>]

On Wed, 7 Apr 2010, Ilari Liusvaara wrote:

> On Wed, Apr 07, 2010 at 09:54:29AM +0400, Vitaly Berov wrote:
> > I suspected the security reasons.
> > 
> > Ok, we work in trusted environment. How can we turn this behavior off?
>  
> It can't be turned off. Protocol requires client to recompute hashes
> as they are not explicitly available in transport stream (must be inferred
> instead).
> 
> > >This being said, you should never have to wait 6 hours for that phase to
> > >complete.  It is typically a matter of minutes if not seconds.
> 
> The reasons why it might take 6 hours (offhand from memory):
> 
> - Extremely large repo

Six hours is still way out of the expected computational requirement.  
That's an expected time for an aggressive repack for example, where 
_each_ delta is attempted against a different base up to 250 times.  
But when indexing a fetched pack, each delta is expected to be computed 
only once.

> - Very large files in repo pushing client into swap.

This shouldn't happen since commit 92392b4a which provide a cap on 
memory usage during the delta resolution process.

So without a look at the actual repository causing this pathological 
behavior it is hard to guess what the issue and the required fix might 
be.


Nicolas