Re: That improved git-gui blame viewer..

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 12, 2007, 19:14 UTC
Message-ID: <7v645thto7.fsf@assigned-by-dhcp.pobox.com>
In-Reply-To: <20070612135303.GT6073@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

Show 13 quoted lines

> 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 7 quoted lines

>> I really would like to keep it like that because it is the way 'git'
>> works, and I would feel uncomfortable in filtering out git results, it
>> seems quite fragile to me.
>
> Its not "the way git works".  Its just one way of looking at the data
> in the object database.  And its not as accurate or as interesting
> as what git-blame does.

Again, I would not say "accurate".

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.

Show 8 quoted lines

>> This means that file splits, merges, renames etc.. are handled as much
>> as they are handled in git. IOW *if* 'git rev-list HEAD -- <path>'
>> returns a list of revisions taking in account all of the above, so it
>> will, automatically, do qgit.
>> 
>> BTW _currentlly_ git-rev-list does not do that.
>
> And it may never do it.

Oh, I can guarantee you that git-rev-list will never ever do that. It is to traverse revisions while simplifying with path limiters, and path limiters by definition will not look inside contents. Think of it as asking "Had my project consisted of only arch/i386 and include/asm-i386 directories, what would the history be".

However, adding a new option to "git log" so that you can say 'git log --single-follow=$this_file_at_the_tip $branch' is a separate matter. I think it is a sensible thing to do. But even if we do that, I think --single-follow should limit itself to the rename following of "diff -M/-C" style. It is insane to include another path only because the result did copy&paste only a handful lines out of during its history.