[RFC] How to better assist users in resolving conflicts

[Martin Pool]

2010/1/13 Vincent Ladeuil <v.ladeuil+lp at free.fr>:
> So I stepped back from doing so in the core and decided to leave
> that for GUIs.
>
> The rationale is that:
> 1) We need to provide a scripted way to access the feature,
>
> 2) As soon as we let the user modify the working tree *during* an
> interactive session, there are a lot more checking that needs to
> be done and a lot more work to make the code more robust.

I agree with that.  I just wanted to affirm that the mode of
interaction for the core commands would continue to be a series of
noninteractive shell commands, and that we'd build interactive stuff
on top.   This may be obvious to you but maybe not to others. :)

>    martin> If they're happy with the new diff, and in particular
>    martin> if they've removed all the conflict markers, I think
>    martin> we should treat it as resolved.  I don't feel that
>    martin> requiring 'bzr resolve' as we do at the moment is a
>    martin> particularly good tradeoff, and increasing that work
>    martin> by requiring 'bzr resolve --done' would be a step in
>    martin> the wrong direction.
>
> We can hook --auto into commit or even status then.

That could be good.  I would say _not_ status because that's at the
moment a readonly command and it would be disturbing if running it
caused either .THIS files or conflict information to be lost.

>    martin> Some people might want to know all the files that
>    martin> were ever conflicted in the current merge, even if
>    martin> they've now resolved the conflict.  For example they
>    martin> might want to review their diff especially closely.
>
> I'm less sure about that one as I think people want to get rid of
> the conflicts and just focus on the remaining ones.
>
> But if we want to do it, we'll need to keep some sort of state in
> the conflicts objects or add a separate file to support that.
>
> Introducing a separate file may help address the transition from
> one format to the other though...

Straw man: conceptually, there is a list of conflicts in the working
tree, with a column that says whether that concept is 'done' or not.
By default 'bzr conflicts' lists only non-done conflicts, but you can
choose to show them all.

I'm not sure if that really matters though.  If you want to see them
you can remerge or just compare the file to the other revisions.

> I switch from this/other to mine/theirs as I thought it made them
> more "personal". When I merge a branch into my current working
> tree, I clearly know which is "mine" and from there I deduce what
> is "theirs" without thinking about *who* is theirs :)

ok

>    martin> There's a related bug about making sure people don't
>    martin> accidentally add .moved etc files.  Perhaps that can
>    martin> be handled by making sure they're unversioned, having
>    martin> a special category of conflict files, and refusing to
>    martin> add or commit them.
>
> Yes, I didn't mention it as it requires better support to make
> sure the conflict objects unambiguously knows which files have
> been generated. NonDirectoryParent for example does not store the
> '.new' path forcing us to guess it at resolution time. There is
> also ParentLoop that deals with '.moved' dirs where both paths
> *are* versioned which make the decision harder (if '.moved' was
> '.THIS or '.OTHER' it would be clearer though).

I agree.

> Also, I toyed a bit with following idea: for text conflicts, bzr
> leave the working tree in a unusable state (rightly so IMO) by
> leaving conflicted regions (you're not supposed to be able to
> compile such files). We don't do that for all tree shape
> conflicts, instead there is HandledPathConflict (the base class
> for many conflict classes) that pre-resolve the conflict (in
> essence doing --keep-mine or --take-theirs upfront).
>
> When possible, I'd like to *avoid* doing that and instead leave
> FILE.THIS and FILE.OTHER in the working tree (ParentLoop may be
> problematic though) so the user can better understand what is
> coming from where and what the conflict is about[1]. The drawback
> is that the working tree is less usable after a merge.

I'm not sure I understand this well enough to say.  Giving the user
all the relevant reference data in the tree sounds good, if they can
understand what to do with it.  On the other hand just giving them two
similar directories may be unhelpful compared to giving a good message
about the situation from bzr resolve.  Do you have a specific example
where it can help?
Hm, maybe.

It seems like many of the tree shape conflicts people hit now are ones
where they really just want to essentially click Continue: like in
deleting of a directory that contains unversioned files, or joining
file ids, there may be some value in telling the user about the
conflict but ideally if there is a reasonable default resolution, it
should be easy to get there with a single command.  Obviously there
are others where the user does need to have input.

istm the principles should be (and this seems consistent with what you have):

The presence of conflicts shouldn't leave the working tree unusable,
it should just block commit.  (It would be interesting, but rather out
of scope, to let you force a commit with conflicts, so you can record
the work in progress - this points to an interesting implementation
idea which is to store the conflict list in .bzrmeta.)

You should be able to find out what kind of conflict has occurred and
what to do about it by asking bzr resolve and/or conflicts at any time
while the tree is conflicted.  (ie you shouldn't have to remember what
bzr merge says.)

You should be able to get a reasonable resolution to any kind of
conflict by using only options to bzr resolve.  Obviously you might
also want to do some manual file edits or rearrangements, but you
shouldn't need to.  This seems to be pretty much covered by  resolve
--mine and --theirs, though you might need some more options in the
case of directory rearrangements.

And something about how the conflict-information files are handled.  I
don't know what but I have a feeling we should have some kind of
systematic solution to avoid them being committed.

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