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

From: Nicolas Pitre <nico@fluxnic.net>
Date: Apr 7, 2010, 14:08 UTC
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:

Show 15 quoted lines

> 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