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

["Stephen R. van den Berg" <srb@cuci.nl>]

Paolo Bonzini wrote:
>> - 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).

>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.

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

>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.

>  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.

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