[RFC] How to better assist users in resolving conflicts

[Martin Pool]

2010/1/13 Vincent Ladeuil <v.ladeuil+lp at free.fr>:
> So far we have only one command when it comes to resolving the
> conflicts: 'bzr resolve' with 'resolved' alias.

It would be a bit confusing to have 'resolve' and 'resolved' exist as
different commands, so I'd like to see if we can I think, as part of
<https://bugs.edge.launchpad.net/bzr/+bug/506265> we should remove the
'resolved' alias.

It looks like you're planning to keep the general model that after a
merge your working tree is marked with some things as conflicted,
which I think is fine.  We can then let the user deal with the
conflicts either by running a sequence of non-interactive commands, or
by popping into something that asks them questions about a whole
series of conflicts.  That interactive resolution could even be
optionally automatically kicked off by merge.  Even in interactive
mode, it should be able to save out the current conflict state into
the tree so that you can come back to it later.

This also relates a bit to remerge, which could be cast as letting you
restart the merge process on a particular file or directory, either
because you want to try different options or because you made a
mistake.


> I've started working on
> https://code.edge.launchpad.net/~vila/bzr/conflict-manager/+merge/16785
> to help users resolve conflicts and encounter some issues.
>
> The first one is that the actual command roughly provides two
> features:
>
> - mark a conflict as resolved and delete the generated helper
>  files,
>
> - check that a text conflict has been resolved.
>
> This can be applied to all conflicted files (--all) or to a set
> of specified files (via globing) including a single file (one
> conflict can be addressed by any of its related paths).
>
> There is also a special mode 'bzr resolve --auto' that will
> detect which text conflicts has been resolved and mark them as
> such. It works for the text conflicts *only* (and as such is
> incompatible with --all).
>
> The first question raised by the early reviews are whether we
> should define new commands to introduce the new ways to resolve
> the conflicts.
>
> In my opinion 'bzr resolve' should be the preferred command to do
> that and we may keep 'bzr resolved' to simply mark the conflicts
> as resolved.
>
> But then, since that requires break the compatibility with
> earlier releases, we may as well keep it as is, delete the alias
> and just have an option to mark the conflict as a way to resolve
> a conflict among the new ones introduced from now.
>
> In the proposed patch I've called it 'done'.

istm that for a simple text conflict in a source file, it's actually a
bit of a waste to make the person specifically mark it as resolved.
If they're happy with the new diff, and in particular if they've
removed all the conflict markers, I think we should treat it as
resolved.  I don't feel that requiring 'bzr resolve' as we do at the
moment is a particularly good tradeoff, and increasing that work by
requiring 'bzr resolve --done' would be a step in the wrong direction.

There might be some people who do want this special step as an option.

Making commit do some kind of automatic resolution could be handled
separately from your work though.

Some people might want to know all the files that were ever conflicted
in the current merge, even if they've now resolved the conflict.  For
example they might want to review their diff especially closely.

> So, what are these new ways ? As a first step I define only two:
> - keep mine: refuse the merged change,
> - take theirs: take the merged change.
>
> This is appropriate for tree shape conflicts but for text
> conflicts, we may add:
> - prefer mine: in conflicted regions, retain my changes,
> - prefer theirs: in conflicted region get rid of my changes,
> - take both: take my changes and the merged ones.
>
> I think their usage will be limited but still useful (and the
> proposed patch doesn't implement them). Manually resolving the
> conflicts ought to stay the preferred way though.
>
> I started with 'take this' and 'take other' (to match .THIS and
> .OTHER) instead of 'keep mine' and 'take theirs' but I'm open to
> suggestions.

I kind of like mine and theirs, as consistent with missing, but
perhaps they're confusing when the other branch came from the person
now running the resolve command.

> I also noticed that we use '.new', '.moved' and '.diverted' in
> various cases and I think we should stick with '.THIS' and
> 'OTHER' when possible as the former are less obvious to casual
> users.
>
> And just to mention them (the main goal is to get feedback on
> whether we want new commands or not), a couple of other
> issues/ideas:
>
> - There are some inconsistencies in the way we generate the
>  conflicts as sometimes we give priority to the merged version
>  and sometimes we give priority to the version present in the
>  working tree,
>
> - The actual implementation is currently unique for all working
>  tree formats and that makes it hard to change the attributes
>  (to add some missing data including the base revision used for
>  example). I'd like to find a way to *avoid* bumping the format
>  by considering that people don't upgrade bzr when they have a
>  working tree with conflicts (one escape path could be to
>  provide a way to just allowing clearing the conflicts),
>
> - 'bzr conflicts -v' could give a more verbose explanation of
>  what led to the conflicts mentioning the actual paths and the
>  possible actions,
>
> - make --auto handle more conflict types (see comments in the
>  patch),

Those sound pretty reasonable to fix.

I guess this leaves me wondering: what happens if I just say 'bzr
resolve F' without saying how to resolve it?  Maybe it should tell me
what my options are?

There's a related bug about making sure people don't accidentally add
.moved etc files.  Perhaps that can be handled by making sure they're
unversioned, having a special category of conflict files, and refusing
to add or commit them.

-- 
Martin <http://launchpad.net/~mbp/>