Re: Comments on recursive merge..

From: Fredrik Kuivinen <freku045@student.liu.se>
Date: Nov 8, 2005, 21:02 UTC
Message-ID: <20051108210211.GA23265@c165.ib.student.liu.se>
In-Reply-To: <Pine.LNX.4.63.0511081254520.2649@wbgn013.biozentrum.uni-wuerzburg.de>

On Tue, Nov 08, 2005 at 12:58:50PM +0100, Johannes Schindelin wrote:

Show 12 quoted lines

> Hi,
> 
> On Mon, 7 Nov 2005, Linus Torvalds wrote:
> 
> > Is the recursive thing noticeably slower for the "easy" cases (ie things 
> > that the old regular resolve strategy does well)?
> 
> IIRC recursive does nothing else than recursively merging the merge-bases 
> (granted, in a clever way). So if there is only one merge-base, the only 
> slow-down would be the startup of python (which is probably worth it, 
> anyway).
>

I haven't done any real measurements but my feeling is that the recursive strategy is at least not very much slower than the resolve strategy.

In the single-common-ancestor case I can think of the following things which may make a difference speed wise:

* The recursive strategy is written in Python
* The code for finding common ancestors is also written in Python and
  is probably a bit slower than git-merge-base.
* git-diff-tree -M --diff-filter=R <common ancestor> <branch> is
  executed twice, once for each branch.

On the positive side the code which corresponds to git-merge-one-file in the git-resolve case is also written in python, we can therefore avoid some forks and execs.

Show 9 quoted lines

> > It's certainly an option to just do what I just did, namely use the 
> > default one until it breaks, and then just do "git reset --hard" and re-do 
> > the pull with "-s recursive". A bit sad, and it would be good to have 
> > coverage on the recursive strategy..
> 
> We already have a fallback list: after really-trivial, try automatic, ...,
> try resolve. Why not just add recursive? So, if even resolve failed, just 
> try once more, with recursive.
>

I don't think this is a very good idea for two reasons. The first one is that there are some merge scenarios involving renames which should be conflicts but are cleanly merged by git-resolve.

The second reason is that with the fall back list the recursive strategy will only be used in the strange corner cases and will thus not get nearly the same amount of testing it would get if it was the first choice (or directly after the really-trivial merge).

- Fredrik