Re: Automatic 3 way merge for conflicts

[Kai Willadsen <kai willadsen gmail com>]

On 19 December 2012 07:06, Piotr Piastucki <leech miranda gmail com> wrote:
> On 12/18/2012 08:13 PM, Kai Willadsen wrote:
>
>
> Sorry, but I'm pretty opposed to opening auto-merge by default for
> conflicts. What I expect to see when I open a conflict is MERGED, not
> BASE, and we can't guarantee that the result of our merge will be
> anything like MERGED.
>
> Since the auto-merge code does similar job to most VCSs when
> it comes to merging 2 files with common ancestor the result
> should be pretty much the same as MERGED.

While I completely agree, it's the 'pretty much' bit that bothers me.
I love the auto-merge mode for non-VC managed stuff, or for VCs with
limited merging capabilities. For situations where I trust the VC
merge, I'd personally rather work with fixing its conflicts rather
than remerging by ourselves... at least by default. As I said, I'm
*very* happy for switching to auto-merge to be a user-initiated action
in the case of a conflict.

> Personally, I do not really care if the result of the merge presented
> by the UI is exactly the same as MERGED as long as the result is reasonable
> and the UI allows me to resolve the conflicts easily.
> TortoiseSVN opens conflict solver automatically for conflicts and I must
> admit it is a quite useful feature. But it's just my opinion :)
>
>
> As an aside (that's even more work), it would be extra awesome to
> support diff3-style conflict markers, so that when we get conflicts,
> we don't show the useless left/right conflict portions, but show the
> ancestor portion of the file in that position.
>
>
> Well, that's exactly what auto-merge does.
> I am afraid that trying to parse markers in MERGED and replacing conflicts
> with proper chunks from BASE instead might lead to some errors as it is not
> always obvious which chunk to use.

I definitely don't want to be replacing text in MERGED with text in
BASE. The only correct possibility here is to use ancestor information
that already exists in MERGED, if it's there.

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.

cheers,
Kai