Re: git clone: very long "resolving deltas" phase
- From
- Vitaly <vitaly.berov@gmail.com>
- Date
- Apr 12, 2010, 15:31 UTC
- Message-ID
- <4BC33CE3.4030103@gmail.com>
- In-Reply-To
- <alpine.LFD.2.00.1004101617460.7232@xanadu.home>
Hello,
On 04/11/2010 04:50 AM, Nicolas Pitre wrote:
Show 27 quoted lines
> 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).