Rogan Dawes wrote:
quoted text
>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.

quoted text
>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).

quoted text
>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."
--
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