Re: What's cooking in git.git (Feb 2009, #05; Mon, 16)

From: Jeff King <peff@peff.net>
Date: Feb 17, 2009, 19:30 UTC
Message-ID: <20090217193027.GA16093@coredump.intra.peff.net>
In-Reply-To: <7vfxid8phr.fsf@gitster.siamese.dyndns.org>

[oops, resend as I screwed up Jonas' address in the last one]

On Mon, Feb 16, 2009 at 11:57:36PM -0800, Junio C Hamano wrote:

Show 13 quoted lines

> * jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
>  + blame: show "previous" information in --porcelain/--incremental
>    format
>  + git-blame: refactor code to emit "porcelain format" output
> 
> This gives Porcelains (like gitweb) the information on the commit _before_
> the one that the final blame is laid on, which should save them one
> rev-parse to dig further.  The line number in the "previous" information
> may need refining, and sanity checking code for reference counting may
> need to be resurrected before this can move forward.
> 
> I thought recent tig discussion may blow new life into it, but is this
> unneeded?  If so I'd rather revert it (or discard after 1.6.2).

I never got a chance to look closely at this patch series; Jonas ended up implementing something in tig which does a diff-tree to guess where we want the view to go:

  http://repo.or.cz/w/tig.git?a=commitdiff;h=b6d0d41e01e4e435385db260cf34fd5d9069d782

It has been working pretty well for me in practice. I'm sure that blame could do it faster internally, but it really isn't performance critical, as it is triggered by user input.

So a blame implementation might help other callers, but I don't think there is much motivation from tig's point of view.

-Peff