git and bzr

[Linus Torvalds]

On Tue, 28 Nov 2006, Johannes Schindelin wrote:
> 
> On Tue, 28 Nov 2006, Jakub Narebski wrote:
> 
> > [... some reasons why git-annotate is not just your regular annotate ...]
> 
> You should also mention that git-annotate can follow code movements 
> through file renames.

.. and within the same file, and _copied_ from other files.

A good example of this is still just doing a

	git blame -C revision.c

because that "revision.c" file was created by splitting the old 
"rev-list.c" into two files (revision.c and rev-list.c). And the fact that 
"git blame" catches it and shows it in a very natural format is really 
quite nice.

(rev-list.c has since been renamed to "builtin-rev-list.c", so if you want 
to see the "other" side of the split, just do

	git blame -C builtin-rev-list.c

in order to realize how well git blame follows both renames _and_ pure 
data movement).

The reason this is a good example is simply the fact that it should 
totally silence anybody who still thinks that tracking file identities is 
a good thing. It explains well why tracking file identities is just 
_stupid_.

You simply couldn't have done that kind of split sanely with file identity 
tracking (well, that one only had a single copy, so you could argue that a 
file identity tracker with copies could have done it, but the fact is that 
(a) they never do and (b) "git blame" can equally well track stuff that 
comes from _multiple_ different "file iddentities").

Such a "multiple sources" case can actually be found by doing

	git blame -C tree-walk.c

which (correctly) figures out that the code comes from both merge-tree.c 
(the "entry compare/extract" functions)_and_ from sha1_name.c (the 
"find_tree_entry()" function). 

So yes, "git blame" is a _hell_ of a lot more powerful than anybody elses 
"annotate", as far as I know. I literally suspect that nobody else comes 
even close.

		Linus