Re: Automatic 3 way merge for conflicts

[Kai Willadsen <kai willadsen gmail com>]

On 20 December 2012 16:44, louis <louis obsidian com au> wrote:
> Seems I didn't send a previous email to the list (oops), but my current
> thoughts below.
>
> Firstly, bug report up:
> https://bugzilla.gnome.org/show_bug.cgi?id=690469
>
>> In other words, if our MERGED file has diff3 conflict markers (rather
>> than the more common two-way conflict markers), we can reasonably
>> strip out the LOCAL and REMOTE parts of the conflict, which would
>> reliably leave the portion derived from BASE. There's no need to
>> actually consult BASE ourselves, or to make decisions about which
>> chunk to use. We just need to be able to get a diff3 formatted
>> conflict from the VC.
>
>
> It doesn't look straight foward to get diff3 output from git without
> changing config options
> It is possible in bzr and svn
> Although to be honest, even if we have diff3 output, I don't really see the
> point in stripping out the LOCAL / REMOTE bits, as that would make the
> conflict markers invalid and the VCS might get confused if you
> (accidentally) save the resulting file and try to resolve the conflict in
> the VCS.

The point of stripping out the conflict markers is that in Meld, they
don't actually tell you anything. We *already have* the local and
remote versions of the file, sitting side-by-side with the conflict.
Basically, we're doing this:

    AAAA    AAAA
                 BBBB
                 CCCC    CCCC

when we *could* be doing this:

    AAAA    BBBB    CCCC

with no loss of information. Of course, that's for a not-yet-written
diff3 conflict thingy. Currently, it's more true to say that what we
do is this:

            HEYTHERESACONFLICTHERE
    AAAA    AAAA
                 BBBB    BBBB
            HEYTHERESACONFLICTHERE

> The conflicts will ALWAYS have to be resolved manually, and will ALWAYS mean
> changing the base anyway. Stripping out the REMOTE / LOCAL bits would not
> make conflict resolution quicker.

While in many cases you're right, it *should* make it a lot cleaner
and more informative. In particular, if/when we fix things so that we
can do inline highlight for conflict blocks, then it's basically
necessary to strip things out in order to get a sensible highlight
(otherwise, an inline highlight will just match A with A, C with C,
and leave B alone).

> Adding BASE in (where it doesn't exist, if user specifically requests it)
> *does* seem to make resolving things quicker.

Right. All of my suggestions were predicated on the idea of having
BASE information, either on its own, or from a diff3 conflict.

> To me this means what Kai suggested:
>>
>> Now, having said that, in any situation where we have BASE but not
>> MERGED for some reason, I think it would be *awesome* to have a
>> GtkInfoBar-style (MsgArea in Meld) prompt asking whether the user
>> would like to start an auto-merge.
>
>
> I think this bar prompt could be displayed even if we *don't* have merged.
> Show MERGED, but have the bar prompt to do a 're-merge' using auto-merge if
> you want.

If we *don't* have MERGED, but do have BASE (which, btw, would be
weird I think) then yes, we *definitely* want the bar prompt.

> This would mean that even if the VCS isn't configured for (or doesn't
> support) diff3 output, we still have a way of showing the BASE.

Right, but... we can do this now. It's just about whether we want to
trust the VC's merge, or our merge. I personally would prefer to trust
the VC's, even at the cost of not being able to show BASE.

I'm willing to be persuaded out of this position, but it might be
difficult. In fact, it would probably be easier to just convince
various VCs to give us diff3s. :)

>> Fair enough. BTW, it would be awesome to see a way to run this new mode
>> from
>> command line so that it can be used with git mergetool etc.
>> Something like:
>> meld LOCAL BASE REMOTE --output=MERGED --output_is_already_merged_switch
>> or
>> meld LOCAL MERGED REMOTE --base=BASE
>> And then:
>> 1) show regular 3-way diff if MERGED contains no conflict markers
>> 2) alter MERGED content and show 3-way diff if MERGED contains diff3
>> markers (maybe, but not necessarily, offer switching to auto-merge)
>> 3) show regular 3-way diff if MERGED contains non-diff3 conflict
>> markers and offer switching to auto-merge
>
>
> I think doing the above should have the same effect as above - Show MERGED,
> but have the bar prompt to do a 're-merge' using auto-merge if you want.

As in the other response, I'll try to write something up as to how I
think these various scenarios should play out.

> I like the second command line version better.

As do I... though in reality I'm scared of command-line options. Once
added, they pretty much become ABI, and we (or, more recently, I) get
to live with any mistakes encoded in them ~forever.

> Finally,
> I'm actually going on holiday for a month on the 28th and won't get much
> time to work on this further until I get back.
> If someone else wants to take what I've done and add the MsgArea prompt feel
> welcome. Otherwise it might have to wait. I've still found the patches I
> submitted to be helpful in my own working environment as is though :)

I'll take a look when I have time, and push what I can. The auto-merge
changes in particular, however, I'm not willing to merge yet.


Most importantly, while this diff3 and auto-merging stuff is all well
and good, I'd like to get *just* the conflict-starts-a-3-way-diff
changes in, all by themselves with no extra bits. I think that's a
clear improvement that doesn't require any real debate or design
decisions or command-line ABI or any of those nasty things.

cheers,
Kai