Re: Automatic 3 way merge for conflicts

[Louis des Landes <louis obsidian com au>]

I've pushed these patches and made a few minor changes, e.g., to still

have the non-auto-merge case work properly with an output file. So
basically most of this is done!

Awesome, thanks. 

> A re-review would be appreciated.
> The SVN stuff may have to wait though. I've commented on the review,
> specifically my approach to getting filenames was broken anyway, and instead
> I'd have to do a glob for filename.r* and grab the last ones, not
> particuarly nice.

Yeah, it's awful that we would have to do this... I haven't spent any
time looking to see whether there's a nicer way, but grabbing the
highest r-numbers is just really, really dodgy. On the other hand, if
SVN gives us nothing else, then I guess that's what we do.

Looks like, I can't find any other way sadly, will move this to a new bug...

I believe you should be able to pass git -c merge.conflictstyle=diff3
(or similar) while triggering a re-merge, though I haven't tested.
Either way, this doesn't need to be fixed immediately, and we can
reconsider what the default should be before the next release.

The -c argument works, but I can't find any way to do a re-merge without knowing the original merge source.

Either need an equivalent of

$ git remerge

or a way to get the merge source when there is an outstanding merge, which I don't know... 

>> >> 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.
>
> Any new thoughts on this?

I really haven't had the time to do this, no. Since we lack any
handling for diff-3 conflict markers, I don't know that it's a big
deal. As far as I can see, we can do exactly what was outlined above
without any additional command-line parameters... is that likely to
break any external tools or anything?

For now, I'd like to look into adding an infobar prompt to suggest
'Auto-merge' or 'Use existing merge' as options when we launch a 3-way
diff on a conflict.

So to summarize:

* Show MERGED as is by default (should always exist anyway... all VCS's create a MERGED file which exists in place of the existing file)

* Show bar to do remerge (always show this if conflicts?)

Can't see any issues with external tools there, except you will need to run 'resolve' manually to mark conflicts as resolved.

I've noticed two issues with current HEAD, and have uploaded patches for them to the bug:

https://bugzilla.gnome.org/show_bug.cgi?id=690469

https://github.com/Psykar/meld/compare/master...3-way-on-conflict

* BASE is being used, not MERGED by default (my fault)

* The centre pane is being set to read-only (needed to check if it's the existing file, don't change permissions if so)

* I didn't add the git conflict_map in, and include a special case to get MERGED output (seems only way is to get the file itself, can't find a git command for it)

Should possibly also do some checks on the temp files - currently all files used in the diff are set as temp files, whereas sometimes they actually already exist (eg bzr creates them). Not sure how to best handle this...

Louis.