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