Re: [PATCH 0/4] Blame in reverse

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 3, 2008, 19:47 UTC
Message-ID: <7v1w5m201g.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <47F4BE98.8060209@viscovery.net>

Johannes Sixt <j.sixt@viscovery.net> writes:

Show 11 quoted lines

> 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.