From: Vitaly Date: Mon, 12 Apr 2010 15:31:47 GMT Subject: Re: git clone: very long "resolving deltas" phase Message-ID: <4BC33CE3.4030103@gmail.com> In-Reply-To: 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).