Ludovic Brenta <[EMAIL PROTECTED]> writes: > Selon Stephen Leake <[EMAIL PROTECTED]>: > >> 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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
