Marius Vollmer <marius.vollmer@xxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> If we made it easy for Dscho to create the merge M to record my tree as >> the first parent, [...] > > But it _is_ easy for Dscho to do that, isn't it? He just needs to > remember to do the merge the other way around, checking out your branch > and merging his into it. > > This doesn't change much, of course, since we still can't follow a > branch backwards in time reliably. Would it make sense to record > additional information in a merge commit, such as the branch name for > each parent? Then tools could automatically draw the history of the > current branch as a straight line, say. We already have record of that, but I do not think using it is necessarily healthy. There are certainly cases where the relationship between the maintainer and a contributor makes one branch "the primary" in the sense that it is the integration ground for everything under the sun, as opposed to the other one that is "the side branch that was merged" in the sense that it brought in a more narrowly focused set of patches. If you examine the merge commit M Dscho makes in the example in my previous message, it shows that one of the parents was committed by me and the other was committed by Dscho. By following my commits over Dscho's, you will identify which one of the parents of a merge is the mainline. You would perhaps instead of "git log --first-parent" use "git log --mainline=gitster" or something like that. The point is that a convention to follow my commits over Dscho's commits is just as valid as a convention to follow the first parent. It is purely a social convention. A more problematic is that in a distributed environment, there doesn't necessarily such a "mainline vs side branch" relationship exist, and it is not healthy to try to introduce such a concept like "mainline" when there is no such thing. Perhaps Alice and Bob forked at the same point, agreeing between themselves that Alice works on the code updates while Bob updates the documentation as a team of two to produce a new feature. Before they collectively conclude their work and send a pull request to the project management, they will merge their branches to produce the end result that is pullable. From the overall project's point of view, the merge to get their work into the mainline will be "the mainline merges one side branch for the feature", but what about the merges between Alice and Bob while they work together? There is no "this is the mainline and this is a side branch" relationship between what they do. -- 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