Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > Junio C Hamano schrieb: >> Usual "git blame" starts from the latest revision and finds where each >> line came from (i.e. who came up with that brilliant idea, or more often >> who introduced that bug). This new mode starts from an old revision, and >> annotates in reverse --- up to which point each line survived, before it >> got replaced with something else. > > Nice!! Is the result somehow different from > > $ git rev-list --reverse HEAD > /tmp/blame.revs > $ git blame -S /tmp/blame.revs foo.c Doesn't -S read from a graft-like file, where each line shows a commit and then its parents? Come to think of it, I probably should have done: git rev-list --children which is a mirror image of "git rev-list --parents". Unlike the additional "child" header in the output of the log-tree family, that would not have any controversial format or UI design issues. Also the resulting output from such command can then be fed via -S to blame. However, as I mentioned in the message of [4/4], I think showing the commit that "introduced" the line is not useful when blame runs in reverse; blame needs to have a switch to tell it which commit to show (either "the guilty party" or "the ones the guilty party tried to pass blame on") anyway, so even though feeding an upside-down topology to the command via its "-S" can try to mimic what it does, it does not reallysolve what I wanted to do. -- 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
