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

[Vitaly <vitaly.berov@gmail.com>]

Hello,

On 04/11/2010 04:50 AM, Nicolas Pitre wrote:
> core.deltaBaseCacheLimit. Given that your files are "relatively" small
> i.e. in the 4MB range max, then the cache should be able to hold quite
> many of them.  At the moment with its 16MB limit, only a few of those
> objects would evict many objects from the cache quickly.
>
> If this is still not good enough, then you could add a negative delta
> attribute to those large binary files (see
> http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html)
> and repack the repository on the server.  Of course that will make the
> repository larger and the data transfer longer when cloning, but the
> "resolving deltas" will be much faster.  This is therefore a tradeoff.
>
> Another solution which might be way more practical for users of such a
> huge repository is simply to use a shallow clone.  Surely those people
> cloning this repository might not need the full history of the
> repository.  So you could simply use:
>
> 	git clone --depth=10 ...
>
> and have only the last 10 revisions transferred.  Later on the
> repository can be deepened by passing the --depth argument with a larger
> value to the fetch command if need be.
>
>
> Nicolas
>
>    
Thanks for comprehensive answer, Nicolas. Now I see 3 directions to work 
on: cacheLimit, negative delta attributes and shortening the history 
(actually, I don't think "clone --depth" is feasible in our environment, 
but we can try to backup and just purge the history).