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

[Stephen Leake]

"Stephen J. Turnbull" <address@hidden> writes:

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

yes, or a small group (~ 5 people), with a well controlled branching
policy.

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

That we do; each release is a branch, and new work happens both on trunk
for major new features, and on the release branch for patches.
Eventually they get merged together.

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

Yes, that is typical.

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

We often get criss-cross merges with short paths; people do work on the
same branch in parallel.

You are correct that sorting out the conflicts when the path to the
ancestor is long is inherently hard. monotone/DVC presents the relevant
files in a nice way, and allows the user to take their time in sorting
things out. The conflict resolution state is saved on the disk, so you
don't have to resolve all conflicts in one interactive session.

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

Hmm. According to
https://www.kernel.org/pub/software/scm/git/docs/git-rerere.html, 'git
rerere' is for conflicts that happen again on subsequent merges.
monotone (in recent heads, not in the current release) has that for
dropped/modified conflicts; I haven't felt the need for it for other
types of conflicts, but it would be easy to add.

--resolve-conflicts-file specifies the resolutions for one merge; it
does not make sense to save the whole file for a subsequent merge. It
might make sense to save parts of it.

'git rebase' is similar to 'mtn merge'; 'git rebase --continue' appears
to support a "merge" that stops partway thru due to a conflict, which
the user must then resolve before resuming the merge, and getting to the
next conflict.

So the user does not see all conflicts at once, which makes the conflict
resolution harder. It is especially frustrating if you don't know how
many conflicts there are; how much time will be needed to finish the
merge. Is there a git command that lists all conflicts in a rebase
before starting?

When git rebase hits a conflict, it creates a local file with CVS-style
conflict markers. monotone just notes the two file versions, and the DVC
front end pops up an Emacs ediff; that's better than Emacs' CVS conflict
mode.

git then requires 'git add' commit to indicate the conflict resolution.
This leaves the workspace in an odd state; is there a git command that
indicates the workspace is in the middle of an interactive rebase?
Suppose you are interrupted, and come back in a week; can you tell what
state the rebase is in? In monotone, all of the conflict resolution is
done outside the workspace (in <root>/_MTN/resolutions/*), and it is
always clear what is going on.

These are not fundamentally different approaches (they do solve the same
problem), but the details can matter when you do this a lot. I assume
git could be enhanced to be more similar to monotone in this area; I'll
probably be forced to do that when monotone finally dies :(.

-- 
-- Stephe