Re: That improved git-gui blame viewer..

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 11, 2007, 16:05 UTC
Message-ID: <7vveduqxxr.fsf@assigned-by-dhcp.pobox.com>
In-Reply-To: <alpine.LFD.0.98.0706110826590.14121@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 6 quoted lines

> I don't generally do "git blame" very much at all, and I've found that any 
> time I do it (even historically - when I've used bk annotate and even 
> CVS), I have invariably _always_ wanted to go back in history to see the 
> blame of the *previous* version (because the commit that gets blamed 
> initially is simply not interesting, and is just whitespace cleanups or 
> whatever!).

Incidentally I added a small patch to underlying git-blame to let you ignore whitespace changes so that you can blame through them. I do not think I merged it to 'master' yet, but it is trivial and look obviously safe and correct.

Show 7 quoted lines

> So I think git-gui isn't quite there yet, but I think it's getting pretty 
> close. It would need
>
>  - the afore-mentioned bug fixed (I _think_ it is a bug, but maybe you had 
>    some other reason for having two separate columns of commits per line), 
>    so that you can literally click on the *previous* version of a line and 
>    say "I don't care about this commit, I want to see the previous one".

I think the two columns are for "who _placed_ these lines in the final image" vs "where these lines originally came into the history". The former is with -C, and the latter is without.

An option to re-blame starting from the parent commit of what is currently blamed (i.e. "peel" one level) would certainly be interesting but I do not think git-gui has it (yet). Of course it has a not-so-interesting corner case of deciding which parent to follow for a merge, but a merge commit is blamed only for lines that are either evil or conflict fixups, so in practice there is not much to be gained from peeling a merge.