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