Re: [Monotone-devel] Non-modal merge

[Stephen Leake]

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

> On Sun, Sep 23, 2007, Stephen Leake wrote:
>
>> 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.
>
> Yes, I know. But without --show-overlap the output also
> includes all the non-overlapping changes and this confuses one
> dramatically, too. I've not found an option combination for diff3(1)
> which shows the ancestors but not the non-overlapping parts. I've tried
> many combinations of --merge, -A, -E, -x and -X but have not found a
> solution. As CVS also doesn't show the ancestor information, I decided
> that I go this way, too.

I use Emacs ediff to resolve the conflicts (open the file, type M-x
smerge-ediff). It has an option (type "$$") to ignore the
non-overlapping changes. So I don't see them as a problem. I did
before I discovered that option in Emacs ediff :).

Another solution to this problem is to add an option to the montone
internal merger to output conflicts the way diff3 does. Then we can
have it not output the non-overlapping changes, and those changes will
be more consistent with other monotone merges.

The code that does this is in diff_patch.cc merge_via_edit_scripts. I
don't fully understand how it works :). Adding this feature is
probably more work that it's worth, since external diff3 with Emacs
works fine for me. 

I looked briefly at the diff3 sources. The differences between the
algorithms will be in finding the boundaries of hunks. I didn't get
far enough to see what the details of that are.

There is a diff test in monotone/tests/calculation_of_unidiffs; it has
two files - firstfile and secondfile. diffing those two files with
monotone and diff (both default options, except -u on diff) does
produce different hunks; monotone's are smaller (on the few that I
actually looked at - comparing diff outputs is not easy :). Using diff
-u --minimal makes the diff output closer to monotone's, but still not
the same. On the other hand, those two files are extreme examples;
they are nominally the same file from gcc, but one version from 1997,
the other from 2003.

In any case, monotone's diff algorithm is clearly different from
diff3. Whether it's better in some sense is a separate question; for
consistency, it might be worth using it for conflicts as I outlined
above. I'll wait for other comments on this before doing anything.

One data point; I have recently become dissatisfied with the results of
the default merge that CVS does; it often gets the wrong result (by my
criteria). So I'm hoping monotone does a better job - I haven't used
it enough yet to tell for sure, but it hasn't done anything wrong yet.

> But I've now made MTN_MERGE_DIFFUTILS more flexible: it can hold a
> comma-separated list of options. Currently "partial" and "showall" are
> implemented. "showall" is to pass --show-all to diff3(1) now.

Excellent!

>> '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,
>> [...]
>
> I've now replaced the "sh" hack with a variant based on
> execute_redirected(). This is more portable and clear, too.

Also excellent.

Thanks for the mtn/lua lesson :).

Should we add something to monotone.texi describing this? The other
merge tools are not documented at this level. I now see that the
source of std_hooks.lua is included in monotone info, and thus
available even in a binary distribution. So maybe that's good enough.

-- 
-- Stephe