Re: [Monotone-devel] considering no merge-into-dir

[graydon hoare]

"Zack Weinberg" <address@hidden> writes:

> I'm tired and not thinking clearly, but I would like to make two
> observations:
> 
> 1) A useful thing to do on conflict is to create three files with
>    names predictably derived from the base filename: (for example)
>    foo.c.GCA, foo.c.LEFT, foo.c.RIGHT.  With the obvious contents.
>    It is then possible to apply an intelligent third-party merge
>    program such as Ediff (part of Emacs) or the spiffy gui one that
>    comes with MacOS X that I can't remember the name of.

yeah, that might do (unless the files were renamed on each edge).. it
might also work to, say, write out a bunch of "pristine" trees and a
control file:

   tmp/<LCA-manifest-id>/foo/bar.c
   tmp/<LEFT-manifest-id>/foo/bar.c
   tmp/<RIGHT-manifest-id>/foo/bar.c
   tmp/<NEXT-manifest-id>/foo/moved/bar.c
   tmp/conflict-list.txt

but, yeah. something "easily" machine-processable like this is, I
think, slightly better than "<<<" markers, since you can turn the
former into the latter with only a little glue, and anyways your merge
tool might actually make a better overall go at it than monotone's
3-way merger, even on the lines monotone thinks it "got right".

> 2) Regarding the scenario you described earlier, how does this sound?
>    If there's no machine-unresolvable conflict, automatically commit
>    the merge.  If there *is* a machine-unresolvable conflict, commit
>    what would be committed now, but then immediately modify the file
>    again, laying down CVS-style conflict markers. and refuse to let
>    the user commit it until they've resolved the conflict.

"what would be committed now" is nothing. current monotone's behavior
is: if there's an unresolvable conflict, it asks you to resolve it, or
just stops dead, nothing committed.

>    The graph that would then be produced from your scenario looks
>    something like this:
> 
> 
>    ... PARENTPIE --- TROMEYPIE  --  AUTOMERGED --- TROMEYFIX
>                  \-- GRAYDONPIE --/  (broken)  \-- NJS_doesnt_care_about_pies
> 
>   which I believe is the same graph you end up with by leaving stuff
>   alone.  This is *effectively* what CVS does if the merge is machine
>   resolvable, and if the merge isn't machine resolvable it is enough
>   like what CVS does to satisfy principle of least surprise.

I think perhaps you're misinterpreting a bit, but it's a subtle point:
the issue isn't that TROMEYPIE and GRAYDONPIE don't merge cleanly.
they merge automatically with no problem (as far as the line merger is
concerned).

the issue is that tromey might take the opportunity -- if there is a
mechanism in place to casually do so during a normal, successful merge
-- to make some semantic corrections during the merge, and thereby
create a TROMEYMERGE version which actually *fails* to merge with
GRAYDONMERGE in the future, whereas accepting the automerge and
applying a fix post-hoc would not cause a future conflict.

I read from your suggestion, though, the idea of committing a version
with '<<<' markers (or, say, a "conflict" certificate) when there is a
conflict, rather than prompting the user for help or writing out a
temporary directory and killing the merge half way. 

since this is all about UI and gut feelings -- nothing is every really
"correct" when merging -- I can only give my gut feeling, which is
that I like writing out a temporary directory a bit better. surely
there's a limit to how smart a merger can be, and it always *might* be
synthesizing semantically wrong code even when there's no line-level
conflicts.. but there's something just somewhat yucky-feeling about
writing versions into a VC database when the VC software *knows* it's
broken. just my $.02 aesthetic preference.

-graydon