Re: That improved git-gui blame viewer..

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jun 12, 2007, 13:53 UTC
Message-ID: <20070612135303.GT6073@spearce.org>
In-Reply-To: <e5bfff550706120427g7ad9d38bpc34d9ea284ace693@mail.gmail.com>

Marco Costalba <mcostalba@gmail.com> wrote:

Show 9 quoted lines

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

Show 6 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.  Most of the split/merge code is actually
in git-blame and is probably too CPU intensive to slam into the
middle of git-rev-list as a path limiter operator.  But renames
*might* someday be included.

> Going from oldest to newest has this advantage:

It is unclear why you aren't just using `git blame --incremental`. git-blame running in two passes (with and without -M -C -C) can yield some very interesting results on files, like Git's own revision.c. And with the new -w flag that Junio just added, there's even more interesting possibilities...

;-)

-- 
Shawn.