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

From: Stephen R. van den Berg <srb@cuci.nl>
Date: Sep 12, 2008, 06:56 UTC
Message-ID: <20080912065658.GA15391@cuci.nl>
In-Reply-To: <48CA09E7.8090102@dawes.za.net>

Rogan Dawes wrote:

Show 6 quoted lines

>Stephen R. van den Berg wrote:
>>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.

Well, actually, sometimes cherry-pick does pick just one of the (multiple) parents to diff with; also, some people (not I) envisioned using two commits which were not a direct parent and child of one another (I'm not quite sure how that would work, but the model would support it).

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

Yes, possible. But then after cloning, this mapping-cache needs to be recreated, and that would mean that one would have to walk through all commits and calculate all patch-id's, of which then only those few which are referenced need to be stored.

-- 
Sincerely,
           Stephen R. van den Berg.

"Father's Day: Nine months before Mother's Day."