Re: [RFC] origin link for cherry-pick and revert

From: Sam Vilain <sam@vilain.net>
Date: Sep 12, 2008, 02:24 UTC
Message-ID: <48C9D2E8.1000506@vilain.net>
In-Reply-To: <alpine.LFD.1.10.0809111641110.3384@nehalem.linux-foundation.org>

Linus Torvalds wrote:

Show 21 quoted lines

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