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

From: Jonas Fonseca <fonseca@diku.dk>
Date: Feb 17, 2009, 22:28 UTC
Message-ID: <20090217222814.GA19085@diku.dk>
In-Reply-To: <20090217193027.GA16093@coredump.intra.peff.net>

Jeff King <peff@peff.net> wrote Tue, Feb 17, 2009:

Show 16 quoted lines

> On Mon, Feb 16, 2009 at 11:57:36PM -0800, Junio C Hamano wrote:
> > * 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;

Sorry, me neither. Generally, I am all for pushing as much as possible into git, and was also happy to see a recent patch making it possible to launch an editor. Especially, since tig would then benefit if a better heuristic comes along. Unfortunately, I won't be able to offer to do what I think is a request for someone to polish it off.

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

Yeah, tig will be stuck with (falling back to) diff-tree anyway.

-- 
Jonas Fonseca