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

From: Nanako Shiraishi <nanako3@lavabit.com>
Date: Nov 30, 2009, 22:12 UTC
Message-ID: <20091201071234.6117@nanako3.lavabit.com>
In-Reply-To: <7v8wdnooza.fsf@alter.siamese.dyndns.org>

Quoting Junio C Hamano <gitster@pobox.com>

Show 9 quoted lines

> 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.  Perhaps making it
> require to have the same tree as all its parents _and_ a well-known marker
> string in the log message (and nothing else) would be a good start.

I think you can record a merge commit that has an unusual list of parents for this. For example, you can record the latest version twice, as the first and the second parents, and make the previous version the third parent. Because such a merge can't be created with git-merge command, you can reliably tell that it is an unusual 'marker' merge.

No matter what techinique is used to mark the special 'marker', if it happens in real life for two or more people who worked independantly to arrive at the same conclusion, I don't think dismissing it as 'by chance' and discarding the contribution from the second branch is a good solution. If git is meant to work smoothly in projects where more than one person see and accept patches from the same origin, the condition is not met 'by chance'; the tool is by design supposed to handle it as a regular situation.

On the other hand, if you made the marker reliable, I think you don't have to disable this feature by default like you said in your (2).

As a side note, I have a bug to report. I tried this sequence of commands to make sure git-merge doesn't record the same parent twice (the last git-merge is made on the slave branch and tries to have slave, master and slave as its three parents).

 % git init
 % echo hello >world
 % git add . ; git commit -m first
 % echo again >world
 % git commit -a -m master
 % git checkout -b slave master^
 % echo again >world
 % git commit -a -m slave
 % git merge master slave

But I got the "usage: ..." error message from git-merge.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/