[darcs-users] unique features + exponential time issue

Stephen J. Turnbull stephen at xemacs.org
Fri Oct 26 07:52:47 UTC 2007


Petr Rockai writes:

 > Yes, and i maintain that it is correct. Or you also maintain, that if
 > a merge tool cleanly merges following, you would never use it?

Yup.  (Never is too strong, obviously if a project I pull from uses
Darcs, I'm kinda stuck with it.)

 > In other words, you are mixing up different problems, one that textual
 > merge cannot ensure correct semantic merge

I disagree.  I think that "clean textual merge" is a non-goal.  For
example, the git "ours" merge gives a guaranteed clean textual merge,
and furthermore is 100% certain to preserve semantic correctness.
(That is, if the "ours" branch is semantically correct, then the merge
will be too, because the definition of the "ours" merge is to copy the
"ours" branch exactly, and ignore the other branches being merged.)
Of course, in a three-way merge it's almost never what you want (ie,
at a deeper level, it doesn't provide anything close to a semantically
correct merge).

So clean textual merge is a heuristic for the correct semantic merge.
In situations where the heuristic is very risky, such as adjacent
lines in code, a merge tool should flag the merge for humans to
consider.

 > (and if you argue that a case, where clean textual merge causes
 > semantic mis-merge, is a bad thing, then you should never use
 > textual merge at all).

Are you arguing that a semantic mis-merge is a good thing, as long as
it results from a clean textual merge?

In fact, I generally don't trust textual merges of patches that touch
the same file.  Since I have to review the diffs anyway, I prefer to
use tools like ediff to do the merge by hand rather than review the
merged code with diff.



More information about the darcs-users mailing list