Stephen R. van den Berg wrote:
quoted text
> Linus Torvalds wrote:
>> On Fri, 12 Sep 2008, Sam Vilain wrote:
>> 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.
> 
> Quite.
> 
>> You could add it as a 
> 
>> 	Original-patch-id: <sha1>
> 
> That will probably work fine when operating locally on (short) temporary
> branches.
> 
> It would probably become computationally prohibitive to use it between
> long lived permanent branches.  In that case it would need to be
> augmented by the sha1 of the originating commit.  Which gives you two
> hashes as reference, and in that case you might as well use the two
> commit hashes of which the difference yields the patch.

Pardon my confusion, but why include two commit hashes? Surely the 
commit already has its parent, so there is no need to include that in 
your "cherry pick". And if the commit has more than one parent, then I 
doubt you could/should really cherry-pick it anyway.

Besides, you could always augment your local repo with a mapping of 
patch ids to commits/commit pairs to reduce lookup time.

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