"Stephen R. van den Berg" <srb@xxxxxxx> writes: > Junio C Hamano wrote: >>"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. > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
