Paolo Bonzini wrote:
quoted text
>> - At the time of creation, the origin field contains a hash B which refers
>>   to a reachable commit pair (B, B~1).  If B has multiple parents and the pair
>>   being referred to needs to be e.g. (B, B~2), then the hash is followed by
>>   a space and followed by an integer (base10, two in this case),
>>   which designates the proper parentnr of B (see: mainline in git
>>   cherry-pick/revert).

quoted text
>What about just storing *two* hashes?  This way cherry-pick can store
>B~1..B and revert can store B..B~1.  The two cases can be distinguished
>by checking which commit is an ancestor of which.

Valid point, but consider:
The new commit to receive hash A.  The diff between A~1..A and B~1..B
actually defines the relation.  Revert and cherry-pick are symmetrical
operations as far as git is concerned since git tracks content.
So I'm not quite sure if we actually need this extra information, git
already knows it all.

quoted text
>> - git cherry-pick/revert allow for the creation of origin links only if
>>   the object they are referring to is presently reachable.

quoted text
>Will cherry-pick -x create origin links?

I'd propose a cherry-pick -o and revert -o for that.
I wouldn't want to force the text which -x generates into the commit
when origin links are used.

quoted text
>  Also, does the origin link
>propagate through multiple cherry picks?

The origin link is created point-to-point from the object referenced by
cherry-pick/revert to the new commit.  The link creation specifically
does not follow any existing origin links.  If you want the origin link
to point to a deeper origin behind the current, then cherry-pick from
there, no need to fake it.

quoted text
>  If not, how can the origin
>object not be reachable?

That can only happen during a fetch/pull, which doesn't use origin links
to determine transmittability by default.
-- 
Sincerely,
           Stephen R. van den Berg.

"Be spontaneous!"
--
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