Re: Automatic 3 way merge for conflicts

[Kai Willadsen <kai willadsen gmail com>]

On 7 March 2013 12:19, Louis des Landes <louis obsidian com au> wrote:
> Apologies for leaving this for so long...

That's all good. I would have been hesitant to push this into 1.7.1 anyway.

> I've updated the bug report yesterday, with updated patches which simply add
> the ability to do a 3 way diff using existing MERGED output from the VCS.
> (ie no auto-merge)

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!

> 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.

> To save time:
> https://bugzilla.gnome.org/show_bug.cgi?id=690469
>
> > > 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. :)
>
> Do you have a way to convince git/svn to give us diff3s besides editing
> config? (I coudn't find a way from command line only)
> it's possible with bzr (bzr remerge --show-base)

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.

> > > > 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.

cheers,
Kai