Re: [PATCH 0/4] Blame in reverse

[Junio C Hamano <gitster@pobox.com>]

Johannes Sixt <j.sixt@viscovery.net> 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.