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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[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:

> * 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux