Thread (44 messages) flat view 44 messages, 12 authors, 2016-06-15

Re: More precise tag following

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:42:51


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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help