monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] resolving name conflicts; file suturing vs drop


From: Stephen Leake
Subject: Re: [Monotone-devel] resolving name conflicts; file suturing vs drop
Date: Mon, 05 May 2008 08:58:58 -0400
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.1 (windows-nt)

Ludovic Brenta <address@hidden> writes:

> Selon Stephen Leake <address@hidden>:
>
>> I've proposed a rather elaborate method using the output of 'automate
>> show_conflicts', editing the resulting file, and commiting with 'merge
>> --resolve_conflicts'. For the case where there is only one conflict,
>> or all the conflicts can be resolved in the same way, we could have a
>> shortcut:
>> 
>> 'merge --resolve_conflict="resolve_content_ws"'
>> 
>> Hmm. I guess in your case, since you are doing 'propagate', that would
>> really have to be:
>> 
>> 'propagate development vendor --resolve_conflict="resolve_content_ws"'
>> 
>> Although then "ws" is ambiguous; it could be either development or
>> vendor. Sigh.
>
> Not really. In my case, ideally I should only propagate one way
> (from vendor to development). So, when propagating from vendor to
> development, all I really need is a way to resolve all non-content
> conflicts by ignoring the changes made in the vendor branch.
>
> For content merges, emacs allows to use "default-A" or "default-B".
> If the same was available for non-content conflicts I would be
> happy.

Ok, that makes sense.

So if:

'propagate vendor development --resolve_conflict="resolve_content_ws"'

interpreted "ws" to be 'development' (ie, the second argument), it
would do what you want. And it's reasonable; the target of the
propagate is where the merge conflicts must be resolved.

We should look at all of the 'merge' commands and see if they need to
support --resolve_conflict.

-- 
-- Stephe




reply via email to

[Prev in Thread] Current Thread [Next in Thread]