Stephen Leake <stephen_le...@stephe-leake.org> writes: > I've pushed rev 6c4dfef59abaf41783e202dc79fada774d2332a6 on > nvm.issue-209; it has two new tests: > > resolve_conflicts_dropped_modified_2 showing this use case: > -- A > -- / \ > -- M1 D > -- | \ | > -- M2 P > -- \ / > -- Q > -- > -- The file is modified and merged into the dropped branch twice. > > > and resolve_conflicts_dropped_modified_upstream_vs_local showing that > use case. > > All tests pass on mingw, except one that also fails in nvm. > > I think the dropped_modified code is complete, except for addressing the > repeated conflicts in the upstream_vs_local case.
I've pushed branch nvm.issue-209.file_attribute, implementing the attribute mtn:resolve_conflict to address the upstream_vs_local case. Getting the conflict resolution from the attribute turned out to be quite simple, but there are two remaining user interface issues. First is how to show the attr-specified resolution in the conflict display from 'show conflicts' (see the FIXME in resolve_conflicts_dropped_modified_upstream_vs_local). Second is whether to require --resolve_conflicts on all merge commands in order to use the attribute. Requiring --resolve_conflicts keeps all the current conflict messages from the merge commands when no resolution is given. That's not as transparent as I'd like, but deleting the requirement for --resolve_conflicts requires more significant changes to the conflict resolution code, to get the current messages when no resolution is supplied (see the failing test update_with_pending_modification). So I wanted some feedback before I start that work. -- -- Stephe _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
