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

Re: More precise tag following

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Jan 27, 2007, 17:36 UTC
Message-ID
<Pine.LNX.4.64.0701270925080.25027@woody.linux-foundation.org>
In-Reply-To
<epfulr$787$1@sea.gmane.org>
On Sat, 27 Jan 2007, Jakub Narebski wrote:
> 
> On the other hand IIRC Mercurial, due to its repository structure, has some
> problems with file copying and renames
This is not a hg-only problem.

This is the SAME and FUNDAMENTAL problem that you have any time you think "file identity" matters.

Yes, it's what makes "blame/annotate" fast. But I have tried, over and over again, to explain why it's fundamentally broken (regardless of any blame thing).

So I will just say once again: don't try to make "blame" faster. You can only do so by introducing MUCH MORE serious problems in other parts.

This was a very early design decision in git. It was discussed within hours of me releasing the first version of git. Yes, "git blame" is relatively slow, and it is very very fundamental. It's fundamental exactly because git avoids the mistake that *everybody* else has done.

The upside? I just sent a patch that should make it possible to do a "cool blame" that doesn't feel slow, and in fact allows some nice eyecandy effects (well, it would allow it, if I just knew tcl/tk or something like that: it needs a canvas to draw the existing file into, and then filling in the incremental data as git-blame finds it).

It's going to be tons more fun to watch than any CVS/SVN annotate has ever been. Trust me. I bet that you'll feel that "git blame" is *too* fast, and you'll want the graphical viewer to have a "slow down" flag, just so that you can appreciate the blame building up!

[ Ok, that may not be true for everybody, but having played with "git 
   blame --incremental" a bit I really think it would be a bit cool to 
   have that "slow down" mode, and start things with a really tiny font 
   so you could see the blame build up over a file!
   I'm not kidding you. Eyecandy! And it literally would need git to slow 
   down to make it more human-friendly! ]

The other upside? EVERYTHING ELSE IS FASTER. And I really mean *everything*. Yes, "git blame" is slower than SVN. It will remain so, unless somebody either overrides my objections, or some alien intelligence comes up with something _really_ clever. But look at it this way: blame may take a few seconds, but that's a big part of why you can do merges of things that have tens of thousands of files in half a second.

Things that you would need to go brew a cup of coffee for in some other environments are basically _instantaneous_.

			Linus
Previous: Jakub NarebskiNext: Johannes Schindelin
Message 11 of 92 in “More precise tag following”
  1. Junio C HamanoJan 26, 2007
  2. Junio C HamanoJan 26, 2007
  3. Shawn O. PearceJan 27, 2007
  4. Junio C HamanoJan 27, 2007
  5. Jeff KingJan 27, 2007
  6. Nicolas PitreJan 27, 2007
  7. Simon 'corecode' SchubertJan 27, 2007
  8. Johannes SchindelinJan 27, 2007
  9. Simon 'corecode' SchubertJan 27, 2007
  10. Jakub NarebskiJan 27, 2007
  11. Linus TorvaldsJan 27, 2007
  12. Johannes SchindelinJan 27, 2007
  13. Simon 'corecode' SchubertJan 27, 2007
  14. Johannes SchindelinJan 27, 2007
  15. Simon 'corecode' SchubertJan 27, 2007
  16. Nicolas PitreJan 27, 2007
  17. Linus TorvaldsJan 27, 2007
  18. Linus TorvaldsJan 27, 2007
  19. Junio C HamanoJan 27, 2007
  20. Linus TorvaldsJan 27, 2007
  21. Junio C HamanoJan 28, 2007
  22. git-blame --porcelain: quote filename in c-style when needed.Junio C Hamano, Jan 28, 2007
  23. git-blame --incremental: don't use pagerRené Scharfe, Jan 28, 2007
  24. Junio C HamanoJan 28, 2007
  25. Junio C HamanoJan 28, 2007
  26. René ScharfeJan 29, 2007
  27. git blame --progressJunio C Hamano, Jan 29, 2007
  28. Simon 'corecode' SchubertJan 29, 2007
  29. Alex RiesenJan 29, 2007
  30. Matthias LederhoferJan 29, 2007
  31. Junio C HamanoJan 29, 2007
  32. René ScharfeJan 29, 2007
  33. Linus TorvaldsJan 29, 2007
  34. Junio C HamanoJan 30, 2007
  35. Linus TorvaldsJan 28, 2007
  36. Junio C HamanoJan 28, 2007
  37. Linus TorvaldsJan 28, 2007
  38. Junio C HamanoJan 28, 2007
  39. document 'blame --incremental'Junio C Hamano, Jan 28, 2007
  40. Junio C HamanoJan 28, 2007
  41. Jeff KingJan 28, 2007
  42. Junio C HamanoJan 30, 2007
  43. Shawn O. PearceJan 30, 2007
  44. Linus TorvaldsJan 30, 2007
  45. Junio C HamanoJan 28, 2007
  46. Shawn O. PearceJan 29, 2007
  47. Junio C HamanoJan 29, 2007
  48. Shawn O. PearceJan 29, 2007
  49. Linus TorvaldsJan 29, 2007
  50. Simon 'corecode' SchubertJan 29, 2007
  51. Theodore TsoJan 29, 2007
  52. Linus TorvaldsJan 29, 2007
  53. Jakub NarebskiJan 29, 2007
  54. Shawn O. PearceJan 29, 2007
  55. Jakub NarebskiJan 29, 2007
  56. Shawn O. PearceFeb 9, 2007
  57. David KågedalJan 31, 2007
  58. David KågedalJan 31, 2007
  59. Peter EriksenJan 31, 2007
  60. David KågedalJan 31, 2007
  61. Peter EriksenJan 31, 2007
  62. Jakub NarebskiJan 31, 2007
  63. David KågedalJan 31, 2007
  64. Simon 'corecode' SchubertJan 27, 2007
  65. Johannes SchindelinJan 27, 2007
  66. Simon 'corecode' SchubertJan 27, 2007
  67. Johannes SchindelinJan 27, 2007
  68. Jakub NarebskiJan 27, 2007
  69. Linus TorvaldsJan 27, 2007
  70. Linus TorvaldsJan 27, 2007
  71. Jakub NarebskiJan 27, 2007
  72. Linus TorvaldsJan 27, 2007
  73. Chris LeeJan 27, 2007
  74. Theodore TsoJan 28, 2007
  75. Linus TorvaldsJan 28, 2007
  76. David LangJan 28, 2007
  77. Nicolas PitreJan 29, 2007
  78. Linus TorvaldsJan 29, 2007
  79. Nicolas PitreJan 29, 2007
  80. Chris LeeJan 29, 2007
  81. Eric WongJan 29, 2007
  82. Eric WongJan 30, 2007
  83. Eric WongJan 30, 2007
  84. Eric WongJan 30, 2007
  85. Jakub NarebskiJan 27, 2007
  86. Jeff KingJan 27, 2007
  87. Linus TorvaldsJan 27, 2007
  88. Jeff KingJan 27, 2007
  89. Theodore TsoJan 28, 2007
  90. Randal L. SchwartzJan 28, 2007
  91. Jeff KingJan 28, 2007
  92. Shawn O. PearceJan 28, 2007

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.