"Ralf S. Engelschall" <[EMAIL PROTECTED]> 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
_______________________________________________
Monotone-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
