On 7 March 2013 12:19, Louis des Landes <[email protected]> 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 _______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
