Re: [Monotone-devel] Non-modal merge

[Stephen Leake]

"Ralf S. Engelschall" <address@hidden> writes:

> I've now improved my "diffutils" merger implementation in std_hook.lua.
> One now can use MTN_MERGE_DIFFUTILS=partial to get the results
> of contrib/diff3_keep_conflicts_merger.lua. When combined with
> "merge_into_workspace" as in...
>
> $ MTN_MERGE=diffutils_new MTN_MERGE_DIFFUTILS=partial mtn merge_into_workspace
>
> ...one now gets mostly the operation one is used from "cvs update" and
> "svn update", i.e. a revision is merged into the workspace and conflicts
> are marked for further manual editing before comitting.

Excellent. 

However, --show-overlap removes the 'ancestor' information from the
merged output; sometimes, that info is useful. So I think I prefer
running diff3 without --show-overlap. I'll have to try it some more.

I'm not sure how to allow the user to specify that option; there could
be yet another environment variable; MTN_MERGE_DIFFUTILS_OPTS.
Probably better to just copy the code to .monotonerc and edit it.
Although this is not immediately available as source in a binary
installation.

In addition, I have quibbles:

I'm not sure you should change the name to 'diffutils_new'. Perhaps
that's left over from a development experiment? 

The default behavior is the same as the old (with improved messages),
and get_preferred_merge3_command uses the name "diffutils". If anyone
already has MTN_MERGE set to "diffutils", it will break.


'partial' depends on 'sh', which may not be available on Windows, so
'available' should check for it. Hmm. non-partial diff3utils doesn't
depend on 'sh', so that would be overkill. I guess we need to qualify
the check for 'sh' on MTN_MERGE_DIFFUTILS:

    available = function ()
        --  make sure the GNU diffutils tools are available
        return program_exists_in_path("diff3") and
               program_exists_in_path("sdiff") and
               program_exists_in_path("diff") and
               (os.getenv("MTN_MERGE_DIFFUTILS") ~= "partial" or
                program_exists_in_path("sh"));
    end,

>> It would be nice if the top-level merger code output a summary of
>> conflicts in this case, so it would be easier to keep a list of things
>> to go back and fix, but the current output isn't too bad for that purpose.
>
> I think one needs something like a "mtn list conflicts" which checks
> whether any files still contain conflict markers.

Yes, that would be handy. Although some variant on 'find | grep
"<<<<"' would work (let's not start another exchange on shell vs
built-in commands).

> I think we can now even remove
> contrib/diff3_keep_conflicts_merger.lua.

done.

-- 
-- Stephe