Re: Comments on recursive merge..

[Fredrik Kuivinen <freku045@student.liu.se>]

On Tue, Nov 08, 2005 at 12:58:50PM +0100, Johannes Schindelin wrote:
> 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.

> > 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