Stephen R. van den Berg wrote:
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
