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

Re: Handling large files with GIT

From
Linus Torvalds <torvalds@osdl.org>
Date
Feb 13, 2006, 04:57 UTC
Message-ID
<Pine.LNX.4.64.0602122049010.3691@g5.osdl.org>
In-Reply-To
<Pine.LNX.4.64.0602121939070.3691@g5.osdl.org>
On Sun, 12 Feb 2006, Linus Torvalds wrote:
> 
> If it takes an hour per merge, it _is_ unusable. I consider 15 _seconds_ 
> to be pretty unusable.

Btw, one thing to realize is that git is inherently a lot better at handling lots of files in _subdirectories_, especially if those subdirectories don't change.

I've never used maildir layout, but if it is a couple of large _flat_ subdirectories, git will potentially handle that a lot worse than if you have a hierarchy of directories.

I say "potentially", because if the directories are all mutable and change, then the flat approach is better. But if they tend to have some kind of stability, a lot of git operations (diffing and merging in particular) are able to see that two subdirectories are 100% equal, and will entirely skip them.

This is a large part of why git performs well on the kernel. Most merges don't actually touch all - or even a very big percentage - of the over thousand subdirectories in the kernel. Git can quickly see and ignore the whole subdirectory when that happens - the SHA1 is exactly the same, so git knows that every file under that subdirectory (and every recursive directory) is the same.

In contrast, if you have a million files in one directory, and 10 of them changed, git will still have to check the SHA1's for matches for the other 999,990 files. Which is going to be slow.

That said, I suspect there's space for optimization. 
		Linus
Previous: Linus TorvaldsNext: Linus Torvalds
Message 10 of 39 in “Handling large files with GIT”
  1. Martin LanghoffFeb 8, 2006
  2. Johannes SchindelinFeb 8, 2006
  3. Linus TorvaldsFeb 8, 2006
  4. Linus TorvaldsFeb 8, 2006
  5. Junio C HamanoFeb 8, 2006
  6. Florian WeimerFeb 8, 2006
  7. Martin LanghoffFeb 8, 2006
  8. Ben CliffordFeb 13, 2006
  9. Linus TorvaldsFeb 13, 2006
  10. Linus TorvaldsFeb 13, 2006
  11. Linus TorvaldsFeb 13, 2006
  12. Ian MoltonFeb 13, 2006
  13. Martin LanghoffFeb 13, 2006
  14. Johannes SchindelinFeb 14, 2006
  15. Linus TorvaldsFeb 14, 2006
  16. Sam VilainFeb 14, 2006
  17. Linus TorvaldsFeb 14, 2006
  18. Junio C HamanoFeb 14, 2006
  19. Sam VilainFeb 15, 2006
  20. Junio C HamanoFeb 15, 2006
  21. Sam VilainFeb 15, 2006
  22. Martin LanghoffFeb 15, 2006
  23. Linus TorvaldsFeb 15, 2006
  24. Linus TorvaldsFeb 15, 2006
  25. Linus TorvaldsFeb 15, 2006
  26. Linus TorvaldsFeb 15, 2006
  27. Junio C HamanoFeb 15, 2006
  28. Linus TorvaldsFeb 15, 2006
  29. Linus TorvaldsFeb 15, 2006
  30. Linus TorvaldsFeb 16, 2006
  31. Junio C HamanoFeb 16, 2006
  32. Fredrik KuivinenFeb 16, 2006
  33. Jeff GarzikFeb 13, 2006
  34. Keith PackardFeb 13, 2006
  35. Martin LanghoffFeb 14, 2006
  36. Linus TorvaldsFeb 13, 2006
  37. Martin LanghoffFeb 13, 2006
  38. Greg KHFeb 9, 2006
  39. Martin LanghoffFeb 9, 2006

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.