"Stephen R. van den Berg" <srb@xxxxxxx> 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.
If something is not "parent", you shouldn't be recording it as such.
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.
This applies to one-parent case as well.
Imagine you have two histories, forked long time ago, and have side-port
of one commit:
o---...o---B---A
/
---o---o---...o---X---A'
What side-porting A from the top history to create A' in the bottom
history means is that the change between B and A in the top history, and
no other change from the top history, is applied on top of X to produce
state A' in the bottom history. What B did is not included in the bottom
history.
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.
--
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
