Re: [Monotone-devel] conflict resolution commands

[Stephen Leake]

Stephen Leake <address@hidden> writes:

> Here's what I'm thinking of implementing for a command line interface
> for specifying conflict resolutions. There's a new command group
> 'conflicts', in group 'tree'.
>
> <snip>
>
> conflicts [--conflicts=<file>] resolve_first <resolution>
>     set resolution for first unresolved conflict.

I've refined this a bit. The first implementation required
<resolution> to have the same basic_io syntax as the conflict file.
That's too hard for users to get right.

So this is now:

conflicts [--conflicts=<file>] resolve_first <resolution>
conflicts [--conflicts=<file>] resolve_first_left <resolution>
conflicts [--conflicts=<file>] resolve_first_right <resolution>

'resolve_first' is for file_content_conflicts, which only need a
single resolution. There is only one; 'user <file>', where the user
specifies the location of the manually merged file.

'resolve_first_left', 'resolve_first_right' is for
duplicate_name_conflicts, which require two resolutions. The choices
are:

'user <file>', where <file> gives the location of the manually merged
file.

'drop', drop the node

'rename <file>', where <file> gives the name for the node.

This is partly implemented in n.v.m.resolve_conflicts rev ??

The user commands are recognized, but 'drop' and 'rename' are not
implemented. In n.v.m.automate_show_conflicts, I implemented 'suture'
and 'rename'; I need to copy the rename code and the drop part of the
suture code.

These commands are currently very fragile; it's easy to use them wrong
and confuse things. It should be possible to add sufficient checking
to prevent that; I think the basic command syntax design is a good
one. In particular, it is easy to extend it to other conflicts.

-- 
-- Stephe