"Stephen R. van den Berg" <srb@cuci.nl> writes:

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

Read what you are quoting again and notice I explicitly said "suits the
purpose of *MY* branch better".  In your side-port example, if (perhaps a
critical security bugfix) B does *not* matter for the purpose of *your*
branch (perhaps because you know the product built from the branch you are
cherry-picking into will not be used in a context that would be affected
by the bug), it is perfectly fine to record the cherry pick source as a
parent of A'.

One ramification of this, however, is that you will give wrong impression
that such a branch contains the bugfix B to other people.  By merging A'
(not A) to their history, they think they obtained the bugfix B through
you, but in fact they are *not* getting the fix.  Running diff between A
to A' will reveal that in fact with the "merge" A' you discarded the fix
in B.  This makes your branch that has A' in its history useless for
people other than you.  But it can still be said that the resulting
history suits the purpose of *your* branch.

I said (and I maintain) it is not a good idea *in general*; building that
kind of history is just not a normal thing to do, and it will lead to
confusion unless you are careful and know what you are doing.  I still do
not necessarily agree that what you did is "the normal use case for these
kind of side-port", but people who consider it the normal use case would
be careful and know exactly what they are doing.  It is Ok in that kind of
context.

But just do not recommend it blindly to people who do not understand the
consequences, one example of which is that you cannot get the bugfix B by
merging A' to your branch as I mentioned above.

At that point, the choice becomes between merging from you (i.e. A') or
not merging from you.  The other people may find that merging from you
to honor *your* choice of discarding the bugfix made by B does *not* suit
the purpose of *their* branch, in which case they just do not merge from
you, and that is perfectly fine.

It is all relative --- each owner of history can have different objective
of his own history, and sometimes it contradicts with each other.  I do
not recommend recording A as a parent of A' because it explicitly makes
the objective *your* branch a more specialized one, "this branch does not
care about the bugfix B (among other things you discarded from the
original history that leads to A)", which in general makes it less
agreeable by other people which in turn means it is less useful to them.
--
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