Re: equal-tree-merges as way to make rebases fast-forward-able

Johannes Sixt [off-list ref] writes:

On Montag, 30. November 2009, Junio C Hamano wrote:

quoted

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.