[darcs-users] User interface for conflicts: confusing enough to lose data

[David Roundy]

On Sun, Jun 27, 2004 at 06:22:11PM +0200, Juliusz Chroboczek wrote:
> I've just lived through my first merge conflict with darcs.  It wasn't
> a pretty sight.
> 
> I believe that the user interface that darcs provides for dealing with
> conflicts is extremely confusing; had the project been larger, I might
> have lost some changes, which I hope you agree is worrying.

This is definitely an area that needs work, but since it needs a lot of
work, I'm postponing most of the work until after darcs 1.0.  There are
enough people using darcs for real work that I don't want to destabilize
things by trying to fix this.  Although some of the interface things can be
fixed now (see below), getting conflicts really right is post-1.0
business.

[... description of how the conflict came into existence]

> I started working on merging the conflict, and at some point I became
> confused about what exactly I had done; whence darcs revert.  At that
> point, the file turned out to be back to version 1, with no indication
> whatsoever that patches 2 and 3 were being ignored due to a conflict.
> Neither darcs whatsnew nor darcs changes gave any hint of what's going
> on.  Cloning the repository (darcs get) didn't make the situation any
> different.
> 
> In summary, just doing ``darcs pull; darcs revert'' will make
> conflicts impossible to note by any of the official tools in darcs.
> Once two conflicting patches are in a repository (as opposed to being
> in two repositories with a common ancestor), for all practical uses
> both are lost with no visible indication of the fact.

It would probably be a good idea to add a "re-resolve conflicts" command of
some sort.  This wouldn't be too hard to code, but I'm not sure what I'd
call it.

> CVS and arch solve the issue by making it impossible to commit until
> conflicts are resolved.  This approach cannot be taken by darcs: the
> main reason why darcs is so pleasant to use is that most operations
> are always possible, making the system feel much more responsive than
> the alternatives.
> 
> The obvious fix would be to have revert, pull, push, get and whatsnew
> always mark unresolved conflicts, and darcs changes complain loudly
> about them.  Unfortunately, I'm not quite sure what the right
> definition of an ``unresolved conflict'' is within the data model used
> by darcs.  One possible definition is two patches 2 and 3 such that 2
> and 3 don't commute and there is no patch 4 such that 4 depends on
> both 2 and 3.  I'm not sure, however, how well that corresponds to the
> user's intuitive definition of an unresolved conflict.

An unresolved conflict is a "merger" patch that can be commuted to the
front of the patch stack (i.e. to be the most recent patch).  A conflict
resolution is a patch that doesn't commute with the "merger", which means
that the merger can't commute to be the most recent patch.

Unfortunately, looking for unresolved conflicts is potentially an O(n^2)
problem, since you have to look at O(n) patches that might have conflicts,
and for each one with a conflict, you might have to commute it by O(n)
patches before we find out if it has been resolved.  In practice it's not
likely to be so bad, since usually conflicts are resolved soon after being
created.

Because looking for unresolved conflicts is slow, we don't want to do it if
we can possibly avoid it.  Pull, push and apply look for unresolved
conflicts in the new patches they get, and currently that's all.  Certainly
looking for unresolved conflicts in a get would impose a large performance
penalty, so I'd definitely prefer to put it into a dedicated command (or at
least an optional flag).

> [1] Minor nit: could the markers please be standard diff3 style?  It
>     might not be the best style around, but it's what we're used to 
>     working with.

I'm not sure what diff3 style looks like but the trouble with marking
conflicts in darcs is that it's possible to have an N-way conflict, so
CVS-style marking isn't sufficiently general.  The other problem is that
we have no way of knowing when doing the marking which is "our" change and
which is "their" change.
-- 
David Roundy
http://www.abridgegame.org