git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
VVitaly <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).

Previous: Nicolas PitreNext: Vitaly Berov
Message 21 of 39 in “git clone: very long "resolving deltas" phase”
  1. Vitaly BerovApr 6, 2010
  2. Matthieu MoyApr 6, 2010
  3. Vitaly BerovApr 6, 2010
  4. VitalyApr 6, 2010
  5. Andreas EricssonApr 6, 2010
  6. Nicolas PitreApr 6, 2010
  7. Marat RadchenkoApr 7, 2010
  8. Nicolas PitreApr 7, 2010
  9. Nicolas PitreApr 6, 2010
  10. Nicolas PitreApr 6, 2010
  11. VitalyApr 7, 2010
  12. Nicolas PitreApr 7, 2010
  13. Vitaly BerovApr 9, 2010
  14. Matthieu MoyApr 9, 2010
  15. Nicolas PitreApr 9, 2010
  16. Vitaly BerovApr 10, 2010
  17. Nicolas PitreApr 9, 2010
  18. Vitaly BerovApr 10, 2010
  19. Vitaly BerovApr 10, 2010
  20. Nicolas PitreApr 11, 2010
  21. VitalyApr 12, 2010
  22. Vitaly BerovApr 6, 2010
  23. Nicolas PitreApr 6, 2010
  24. Vitaly BerovApr 7, 2010
  25. Ilari LiusvaaraApr 7, 2010
  26. VitalyApr 7, 2010
  27. Ilari LiusvaaraApr 7, 2010
  28. Jakub NarebskiApr 7, 2010
  29. Nicolas PitreApr 7, 2010
  30. VitalyApr 7, 2010
  31. Nicolas PitreApr 7, 2010
  32. Vitaly BerovApr 9, 2010
  33. Nicolas PitreApr 9, 2010
  34. Vitaly BerovApr 10, 2010
  35. Nicolas PitreApr 7, 2010
  36. Sverre RabbelierApr 7, 2010
  37. VitalyApr 7, 2010
  38. VitalyApr 7, 2010
  39. Nicolas PitreApr 7, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.