Re: [RFC] cherry-pick using multiple parents to implement -x

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

Junio C Hamano wrote:
>"Stephen R. van den Berg" <srb@cuci.nl> writes:
>> The questions now are:
>> - Would there be good reason not to record the backport/forwardport
>>   relationship in the additional parents of a commit?

>In general, I do not think what you did is a good idea.  The _only_ case
>you can do what you did and keep your sanity is if you cherry-picked every
>single commit that matters from one branch to the other.

Wouldn't that be the normal use case for these kind of side-port
references?

>If something is not "parent", you shouldn't be recording it as such.

It depends on what you define to be a parent.  The git repository
doesn't care either way (that's the beauty of the format definition of
the git repository, just as the tree snapshots allow for later more
complicated diff/blame processing history, so do the parent
relationships allow for more complicated parent references which were
not imagined as the repository format was defined).

>Remember, when you are making a commit on top of one or more parents, you
>are making this statement:

> * I have considered all histories leading to these parent commits, and
>   based on that I decided that the tree I am recording as a child of
>   these parents suits the purpose of my branch better than any of them.

That is a statement which depends on the view of the user.  I concur
that up till now, that is what a user says.  But maybe it is possible to
accomodate both the traditional statement and the sideport-statement
without confusing the two.

>This applies to one-parent case as well.

>Imagine you have two histories, forked long time ago, and have side-port
>of one commit:

>If you recorded A' with parents A and X.  Here is what you would get:

>             o---...o---B---A
>            /                \ (wrong)
>        ---o---o---...o---X---A'

>But that is not what you did.  The tree state A' lacks what B did, which
>could be a critical security fix, and you didn't consider all history that
>leads to A when you cherry-picked it to create A'.

>To put it another way, having the parent link from A' to A is a statement
>that A' is a superset of A.  Because A contains B, you are claiming A'
>also contains B, which is not the case in your cherry-picked history.

Which existing git command actually misbehaves because it makes the
above assumption?
-- 
Sincerely,
           Stephen R. van den Berg.

"The future is here, it's just not widely distributed yet." -- William Gibson