Linus Torvalds wrote:
quoted text
> 
> On Fri, 12 Sep 2008, Sam Vilain wrote:
>>  2. make git-cherry-pick have a similar option to '-x', but instead of
>>     recording the original commit ID, record the original *patch* ID,
>>     *if* there was a merge conflict for that cherry pick.
> 
> Actually, don't make it dependent on merge conflicts. Just make it depend 
> on whether the patch ID is _different_.
> 
> It can happen even without any conflicts, just because the context 
> changed. So it really isn't about merge conflicts per se, just the fact 
> that a patch can change when it is applied in a new area with a three-way 
> diff - or because it got applied with fuzz.
> 
> You could add it as a 
> 
> 	Original-patch-id: <sha1>
> 
> or something. And then you just need to teach "git cherry/rebase" to take 
> both the original ID and the new one into account when deciding whether it 
> has already seen that patch.

Yes, right - it's the patch ID changing that's the problem for
git-cherry / rev-list --cherry-pick to be able to spot changes as the
'same'.

Someone else pointed out that git-rebase -i might want to have this as well.

I actually looked into coding this, but there was a little problem with
the way git-revert worked - it builds the commit message before the diff
is calculated.  So there would probably need to be a little trivial
refactoring first before this can be implemented.

Sam.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html