.. 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
