From: Nicolas Pitre <nico@fluxnic.net>
Date: Wed, 07 Apr 2010 14:08:55 GMT
Subject: Re: git clone: very long "resolving deltas" phase
Message-ID: <alpine.LFD.2.00.1004070952290.7232@xanadu.home>
In-Reply-To: <20100407080049.GA14041@LK-Perkele-V2.elisa-laajakaista.fi>

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