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

Re: [Census] So who uses git?

From
Linus Torvalds <torvalds@osdl.org>
Date
Jan 31, 2006, 21:25 UTC
Message-ID
<Pine.LNX.4.64.0601311314030.7301@g5.osdl.org>
In-Reply-To
<20060130225107.GA3857@limbo.home>
On Mon, 30 Jan 2006, Alex Riesen wrote:
> 
> I use git in cygwin for a project with more then 17k files (almost 6M lines).
> It's real slow on ntfs (on 3.2Mhz PIV!)

One thing that git does rely on is a fast "lstat()" system call. The index file means that we almost never need to read the contents of a file to compare, but git _does_ check that files haven't been modified, and doing an "lstat()" on every single file it knows about is the way to do that.

Now, I suspect that you simply can't do basic filename lookups much faster than Linux does them. The Linux VFS layer name caching reigns supreme: the dentries are just incredibly powerful, and the reason Linux kicks ass on many benchmarks.

And yes, git was designed for it. git is _really_ fast on Linux, but any operating system that is so stupid that it has to call down to the low-level filesystem for filename lookup (which is most of them, and from what I have heard, the NT VFS layer is worse than most) will take a lot longer.

This is sadly not something I think you can possibly avoid. Git is literally being as fast as is humanly possible without doing explicit locking. You _can_ avoid the "lstat()" calls if you are willing to always explicitly mark files that you have changed (so that the SCM can stat just _those_ files and ignore all the others), but I personally much prefer being able to use any random tools on the files without having to prepare them some way.

So we could speed it up on cygwin (and yes, it would speed git up a lot even on Linux, but since the cached lstat() case is so fast anyway, I doubt a lot of Linux users care - the biggest win would be on a cold-cache tree). But it would require that you explicitly _mark_ the files you edit some way.

Btw, BK wanted that, and it wasn't _too_ painful. You had to do
	bk edit

to mark a file as being ready to be dirtied, and as a helper command you would use

	bk editor

which would first do the "bk edit" thing and then start up your favourite editor (the usual ${EDITOR:${VISUAL:vi}} rules applied) on it, and it worked fine. We _could_ do the same in git.

I'd just prefer not to.

For small projects (or big projects with fairly few files), it really shouldn't matter. Your 17k files example is hopefully fairly rare..

> But its more intuitive and more powerful than any alternatives here (Perforce,
> SVN and CVS come to mind).
Good to know.
		Linus
Previous: Alex RiesenNext: J. Bruce Fields
Message 22 of 105 in “LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)”
  1. Martin LanghoffJan 26, 2006
  2. Linus TorvaldsJan 28, 2006
  3. Martin LanghoffJan 28, 2006
  4. Linus TorvaldsJan 28, 2006
  5. Junio C HamanoJan 28, 2006
  6. Fredrik KuivinenJan 29, 2006
  7. Junio C HamanoJan 29, 2006
  8. Keith PackardJan 28, 2006
  9. [Census] So who uses git?Junio C Hamano, Jan 28, 2006
  10. Morten WelinderJan 29, 2006
  11. Junio C HamanoJan 29, 2006
  12. Morten WelinderJan 29, 2006
  13. Junio C HamanoJan 29, 2006
  14. Keith PackardJan 29, 2006
  15. Radoslaw SzkodzinskiJan 29, 2006
  16. Greg KHJan 29, 2006
  17. Radoslaw SzkodzinskiJan 31, 2006
  18. Radoslaw SzkodzinskiJan 31, 2006
  19. Junio C HamanoJan 31, 2006
  20. Radoslaw SzkodzinskiJan 31, 2006
  21. Alex RiesenJan 30, 2006
  22. Linus TorvaldsJan 31, 2006
  23. J. Bruce FieldsJan 31, 2006
  24. Alex RiesenJan 31, 2006
  25. Dave JonesJan 29, 2006
  26. Daniel BarkalowJan 29, 2006
  27. Martin LanghoffJan 29, 2006
  28. Mike McCormackJan 30, 2006
  29. Carl BaldwinJan 30, 2006
  30. Johannes SchindelinJan 31, 2006
  31. Carl BaldwinJan 31, 2006
  32. Johannes SchindelinJan 31, 2006
  33. Linus TorvaldsJan 31, 2006
  34. J. Bruce FieldsJan 31, 2006
  35. Junio C HamanoJan 31, 2006
  36. Jon LoeligerJan 31, 2006
  37. Junio C HamanoJan 31, 2006
  38. J. Bruce FieldsJan 31, 2006
  39. Keith PackardJan 31, 2006
  40. Linus TorvaldsJan 31, 2006
  41. Joel BeckerJan 31, 2006
  42. Johannes SchindelinFeb 1, 2006
  43. Sam RavnborgJan 31, 2006
  44. Junio C HamanoJan 31, 2006
  45. H. Peter AnvinFeb 1, 2006
  46. Daniel BarkalowJan 31, 2006
  47. Petr BaudisJan 31, 2006
  48. Junio C HamanoJan 31, 2006
  49. Linus TorvaldsFeb 1, 2006
  50. Junio C HamanoFeb 1, 2006
  51. Daniel BarkalowFeb 1, 2006
  52. Junio C HamanoFeb 1, 2006
  53. Carl WorthFeb 1, 2006
  54. Junio C HamanoFeb 1, 2006
  55. Randal L. SchwartzFeb 1, 2006
  56. Junio C HamanoFeb 1, 2006
  57. Linus TorvaldsFeb 1, 2006
  58. Nicolas PitreFeb 1, 2006
  59. Junio C HamanoFeb 1, 2006
  60. Linus TorvaldsFeb 1, 2006
  61. Nicolas PitreFeb 1, 2006
  62. Junio C HamanoFeb 1, 2006
  63. Nicolas PitreFeb 1, 2006
  64. Junio C HamanoFeb 1, 2006
  65. Andreas EricssonFeb 2, 2006
  66. Linus TorvaldsFeb 1, 2006
  67. Two ideas for improving git's user interfaceCarl Worth, Feb 1, 2006
  68. Junio C HamanoFeb 2, 2006
  69. Carl WorthFeb 2, 2006
  70. Junio C HamanoFeb 2, 2006
  71. Carl WorthFeb 3, 2006
  72. Linus TorvaldsFeb 2, 2006
  73. Linus TorvaldsFeb 2, 2006
  74. Alan ChandlerFeb 4, 2006
  75. Junio C HamanoFeb 4, 2006
  76. Alan ChandlerFeb 4, 2006
  77. Carl WorthFeb 4, 2006
  78. Linus TorvaldsFeb 4, 2006
  79. Carl WorthFeb 6, 2006
  80. Florian WeimerFeb 2, 2006
  81. Carl BaldwinFeb 2, 2006
  82. Daniel BarkalowFeb 1, 2006
  83. Joel BeckerFeb 1, 2006
  84. H. Peter AnvinFeb 1, 2006
  85. J. Bruce FieldsJan 31, 2006
  86. Linus TorvaldsFeb 1, 2006
  87. Linus TorvaldsFeb 1, 2006
  88. "Assume unchanged" gitJunio C Hamano, Feb 9, 2006
  89. "Assume unchanged" git: do not set CE_VALID with --refreshJunio C Hamano, Feb 9, 2006
  90. ls-files: debugging aid for CE_VALID changes.Junio C Hamano, Feb 9, 2006
  91. Junio C HamanoFeb 1, 2006
  92. Linus TorvaldsFeb 1, 2006
  93. Junio C HamanoFeb 1, 2006
  94. Jason RiedyFeb 1, 2006
  95. Julian PhillipsFeb 1, 2006
  96. Linus TorvaldsFeb 1, 2006
  97. Chuck LeverFeb 6, 2006
  98. Martin LanghoffFeb 1, 2006
  99. Linus TorvaldsFeb 1, 2006
  100. H. Peter AnvinFeb 1, 2006
  101. Alex RiesenFeb 1, 2006
  102. Linus TorvaldsFeb 1, 2006
  103. Alex RiesenFeb 2, 2006
  104. Linus TorvaldsFeb 1, 2006
  105. Junio C HamanoFeb 1, 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.