Re: [RFC] origin link for cherry-pick and revert
- From
- Rogan Dawes <lists@dawes.za.net>
- Date
- Sep 12, 2008, 06:19 UTC
- Message-ID
- <48CA09E7.8090102@dawes.za.net>
- In-Reply-To
- <20080912054739.GB22228@cuci.nl>
Stephen R. van den Berg wrote:
Show 21 quoted lines
> 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