Johannes Sixt <j6t@xxxxxxxx> writes: > On Montag, 30. November 2009, Junio C Hamano wrote: >> To avoid that, I think (1) the marker has to be more reliable than just >> "happens to have the same tree", and (2) the traversal done by Porcelains >> (your patches 3 thru 5) by default should be unaware of eqt. >> >> I don't know what a suitable marker should look like, though. The marker >> must be easily identifiable by the lowest level rev-list machinery, so it >> needs to be a sign left somewhere in the commit object. > > Wouldn't the pathspec . be the marker: > > git rev-list HEAD -- . > > follows only one of the branches that have identical trees. Because I am saying that "this commit has two parents and they record the identical trees" is a condition that is too weak to mark a special-purpose merge to bind the latest and an earlier version of a series, your rev-list example command line should not be the way to identify such a mark commit and act differently upon seeing one. Actually your command line is even weaker, I think, although it would not make much difference in real-life. The marker as currently Bernhard implements not only has parents with identical trees, but the tree it has also matches those of its parents. You can make a commit that merges two branches that independently reached the same conclusion (which git is designed to handle as an ordinary event in real life), and amend that commit into an evil merge that has different contents from its parents (which, I suspect, does not have much use in practice), and your rev-list will drop one of the branches for even such a commit, mistaking it as a marker when it is clearly not one. My "it would not make much difference in real-life" in the two paragraphs above comes purely from "such an evil merge would not have much use in practice". We should make sure that "two branches that reached the same conclusion" is not mistaken with a marker this series introduces. -- 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