Re: git blame and cherry-picking

[Jeff King <peff@peff.net>]

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

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

> 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