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