Re: [Monotone-devel] improving show_conflicts

[Stephen Leake]

Derek Scherger <address@hidden> writes:

> Stephen Leake wrote:
>> It turns out there is such a command already; show_conflicts.
>> However, I'd like it to default to the two current heads as merge
>> does. 
>
> I thought the other day that it would be nice if show_conflicts could
> also take one or two --revision options and work something like diff.
> i.e. show_conflicts -r xxx would show the conflicts if you were to
> update the current workspace to the specified rev. 

Ok.

> show_conflicts -r xxx -r yyy would show the conflicts between the
> two specified revisions. 

As it currently does.

> At the time I was thinking that without any -r options it would show
> the conflicts between the current workspace and the revision that
> update would choose as its target.

Ok.

> This kinda collides with defaulting to the two current heads, but
> I'm not so sure that makes sense anyway, as there might be 3 or more
> current heads, 

Yes.

> or one, etc. I suppose it could take the first two heads that merge
> would work with first.

If I ultimately want to run merge successfully, I want show_conflicts
to do exactly what merge would do.

But if I ultimately want to run update succesfully, I want
show_conflicts to do exactly what update would do.

How about 'show_conflicts --merge' and 'show_conflicts --update', in
addition to the current 'show_conflicts rev rev'?

> Note that show_conflicts will list content conflicts for any files
> that have changed on both sides, regardless of whether they would
> merge cleanly or not. It's only looking at the content hash.

Ok. The GUI could then offer to run the mtn internal merger on content
conflicts. So that needs an automate interface as well.

For now, the GUI can just run an external merger; Emacs ediff is fine.

The user may want to preview the changes anyway.

-- 
-- Stephe