Re: [Monotone-devel] conflict resolution commands

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> sorry for the late reply - trying to catch up with your emails ;)

No problem.

>> An example session would be (leaving out the 'mtn' from each command):
>> 
>> merge
>>     -- gives conflicts.
>> 
>> conflicts store <left> <right>
>>     -- rev ids copied from merge output, or use selectors.
>>     -- content conflicts that can be handled by the internal merger
>>     -- have resolutions of 'resolved_internal' at this point.
>>  
>> conflicts show_first
>>     -- decide how to handle it.
>>     -- if resolution requires a user-merged file, use your favorite
>>     -- merger now, store result in _MTN/resolutions/*, or anywhere.
>> 
>> conflicts resolve_first <resolution>
>>     -- template of appropriate <resolution> is given by show_first;
>>     -- copy, paste, edit it here.
>> 
>> -- repeat show_first, resolve_first until done.
>> 
>> merge --resolve-conflicts-file=_MTN/conflicts
>>     -- success!
>> 
>> 
>> Comments?
>
> I miss two things:
>
> a) a way to list conflicts (show_conflicts is not useful any longer if
> some of the conflicts have already been resolved)

We could add a 'conflicts show_remaining [--not_internal]' to list the
remaining conflicts, with an option to not show the ones the internal
line merger can handle.

> b) a plan for some kind of nice "prompt the user for a resolution" UI
> because I think individual verbs are very hard to remember in these
> conflict situations

That's what show_first is intended to be; it lists the actual commands
that could be used to resolve the conflict. See the post after this
for the actual verbs.

Understanding what the verbs mean may require reading the manual, but
I don't think it's very complicated.

> Other than that, I wondered if its generally possible to have more than
> a single conflict on a single node and how the code behaves when
> conflicting resolutions are chosen, f.e. a content conflict and a rename
> conflict. There must not be the resolution "drop the node" for any of
> these two because the other conflict wouldn't get handled, right?

That's a good point; we need a test case.

-- 
-- Stephe