Re: That improved git-gui blame viewer..

From: Jakub Narebski <jnareb@gmail.com>
Date: Jun 13, 2007, 23:20 UTC
Message-ID: <f4ptq3$71v$1@sea.gmane.org>
In-Reply-To: <7v645thto7.fsf@assigned-by-dhcp.pobox.com>

Junio C Hamano wrote:

Show 18 quoted lines

> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
>> Marco Costalba <mcostalba@gmail.com> wrote:
>>> On 6/12/07, Junio C Hamano <gitster@pobox.com> wrote:
>>> >
>>> > (1) Are you emulating CVS-like "a file has an identity, and we
>>> >     follow its changes" model?  How does it handle file split,
>>> >     merge, and code movement in general?
>>> >
>>> 
>>> It uses 'git rev-list HEAD -- <path>' to get the list of revisions
>>> that modified a path,
>>
>> So apparently yes, qgit is emulating CVS.  And yet much better things
>> exist (git-blame).
> 
> I would not use the word "better", as it depends on what you are
> looking for.

[...]

Show 5 quoted lines

> The way Marco describes is a perfectly valid way to satisfy
> expectations of people migrating from CVS.  It's more faithful
> reproduction of CVS annotate behaviour.  In a sense, git-blame
> does too much, but that is exactly why these "accurate and
> interesting" behaviours are optional.

Perhaps the qgit annotating would find it's way in core git as git-annotate (which currently is alias to git-blame + some compatibility options), or as an option (--bottom-up) to git-blame?

On the other hand side, blaming multiple files in parallel has sense I think only for graphical viewer, not for command line command.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git