Re: On the subject of Git, Bazaar, and the future of Emacs development

[Stephen J. Turnbull]

Stephen Leake writes:

 > If I understand what you mean by "bidirectional merging", then monotone
 > handles it nicely (http://www.monotone.ca/).
 >
 > I use monotone for all my projects, and merge back and forth between
 > branches all the time.

When you say "my", do you mean projects that mostly only you work on?
If so, you probably won't run into the problem, unless you're in the
habit of keeping several workspaces on a given branch and you don't
keep them current.  In a one-person, multibranch workflow, you will
typically see DAGs like this:

trunk  0--------A--B--C--D-- ...
        \         /    \
         \       /      \
branch    a--b--c--------d-- ...

and the nature of such workflows is that typically conflicts are
relatively few; you do different things in different branches.
Furthermore, at each merge point (<B> and <d>) there are exactly two
paths from the most recent common ancestor (<c> and <C>,
respectively), which helps to simplify analysis of the merge.

Multi-person, multi-branch workflows admit a nastier kind of geometry,
which the Bazaar developers call "criss-cross merges" for an obvious
reason:

trunk  0--------A--B--C--D--E----- ...
        \         /    \/    \
         \       /     /\     \
branch    a--b--c-----d--e-----f-- ...

and the merge at <f> can be a monstrosity because the structure of the
DAG is little help in disentangling conflicts: the most recent common
ancestor of <f> is <c>, and there are 4 "long" paths between them,
increasing the expected number of conflicts.  If Monotone does handle
these gracefully, that would be *really* cool!

 > I suspect the key feature that makes it work is the conflict
 > resolution tools in monotone;
 > http://www.monotone.ca/docs/Merge-Conflicts.html#Merge-Conflicts

Could be, but I really don't see anything on that page that other
DVCSes don't have, and the note about "the special case of file
content conflicts" which invoke an external merge tool looks pretty
ordinary.  I suspect that --resolve-conflicts-file does something
similar to git's rerere command, or perhaps git's interactive rebase
command.

Steve