Re: git blame and cherry-picking

From: Jeff King <peff@peff.net>
Date: Aug 7, 2008, 18:49 UTC
Message-ID: <20080807184929.GA11691@sigill.intra.peff.net>
In-Reply-To: <AA6BDC98-8800-4031-8C8F-A4BD326BEC1E@midwinter.com>

On Thu, Aug 07, 2008 at 11:37:02AM -0700, Steven Grimm wrote:

Show 5 quoted lines

> No, of course not. But one might want to show the original commit's  
> author instead of the name of the person who did the cherry pick. That's 
> mostly what I'm looking for here; knowing where the change originally came 
> from in terms of the revision graph is occasionally interesting but not 
> nearly as important.

OK. I think that is a cherry-pick -n issue, then, as you mention below.

Show 9 quoted lines

> One could argue that the real issue here is that while "git cherry-pick" 
> preserves the original author and doesn't have the misattribution problem, 
> "git cherry-pick -n" discards the original commit's attribution (though it 
> does keep the commit message). Obviously git doesn't necessarily know 
> whether the cherry-picker made substantial changes before committing and 
> should truly be considered the author, but one of the use cases for the 
> "-n" option is a simple "make sure you don't commit totally broken 
> revisions" where there is little to no additional editing of the patch and 
> keeping the original author would support that use case better.

I don't think it would be hard to stuff the cherry-picked commit's info somewhere and to pull it out during git-commit. git-am and git-rebase -i are already doing something similar. The harder question is what should be done with multiple "git cherry-pick -n" invocations with different authors?

I haven't looked closely at the git-sequencer stuff, but I wonder if some of this will come with it for free. My impression is that the prototype is built on _top_ of cherry-pick, but that the C version will not be, and that cherry-pick can then be implemented in terms of the sequencer.

-Peff