Re: Automatic 3 way merge for conflicts



Apologies for leaving this for so long...

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)

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.

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) 

>> 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? 
 
Cheers,
Louis.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]