GNOME Bugzilla – Bug 749396
Merge tabs always appear after diff tabs
Last modified: 2015-06-06 22:52:21 UTC
This is a minor pain about using Meld; when specifying mixed operation types (in my case, --diff and --auto-merge), Meld will always place the tab with the merge in it last. I currently have this as my merge option: meld --output $MERGED --auto-merge $LOCAL $BASE $REMOTE --diff $BASE $REMOTE --diff $BASE $LOCAL The tab with the three-way merge in it appears last. So I tried again with this command: meld --diff $BASE $REMOTE --diff $BASE $LOCAL --output $MERGED --auto-merge $LOCAL $BASE $REMOTE Same behavior. It's not a huge deal; just means I have to tab over to the last tab before I even know what this merge is going to look like. But it's inconvenient enough that I actually removed the two diffs from my merge action until I had a merge complicated enough to require re-adding them, and then I remembered this little quirk. In my defense, this minor inconvenience is exacerbated by the fact that I actually need to see the two diffs about once every six months. You see, a huge gap of time is usually the reason I need to see the original changes: it's been so long since I made them that I have forgotten what the change entailed and need a refresher. Otherwise, the diffs are just in my way, every time. My solution is just to display the merge tab before the diff tabs. To my knowledge, there's no way to do this from the command line. Can we get a feature to allow that?
So the reason this happens is that --auto-merge is a flag to the comparison created by extra args; it doesn't take arguments itself. I can't off-hand think of a sensible way of doing what you're asking for, short of coming up with an entirely different (and more flexible) command line option for creating diff tabs. I *think* there's a bug report around somewhere about creating a new VCS-tool command line mode for Meld that e.g., git or SVN can use to do exactly what they want in a supportable, explicit way. Is there a reason you can't run three separate meld commands using the -n flag to just create tabs as required?
To be honest, I didn't know about -n; it isn't in my manpage, and the output from `meld --help` isn't terribly helpful: http://pastebin.com/7ib3AQ2i Is there a place to view complete documentation? Anyway, using the info you gave me between these bugs, I have created a script which does basically what I want when called. The reason I can't just plug the commands into my version control system alone is that the version control system seems to expect a single command to begin a merge, which it interprets manually without honoring syntactical devices such as quotes or semicolons. Thus, putting three meld calls in there isn't an option. Either way, the final script is less than beautiful: http://pastebin.com/KmedZHsJ The sleeps are required to prevent the tabs from appearing out of order, which is annoying in general, but made extra-specially annoying by the fact that the most recent tab gets focus. Since GTK loading time varies, the tab order is totally random, and so the focused tab is random, too. The sleep calls I added to fix this are long enough to abate the race condition on my machine but short enough to not be obnoxious. The wait at the end is required to keep the version control system from assuming the merge failed. I'm happy to report, though, that the script still performs correctly if another meld instance is open before it runs (the new meld instance stays active until its tab is closed). This means that I could get away with removing the final ampersand and the wait along with it, but doing so scares me.
(In reply to Josh Ventura from comment #2) > To be honest, I didn't know about -n; it isn't in my manpage, and the output > from `meld --help` isn't terribly helpful: http://pastebin.com/7ib3AQ2i I'm not sure what those CSS errors are about, but I'm pretty confident that it's not Meld causing them. > Is there a place to view complete documentation? It's in --help, but you've got a buggy version of GLib that prevented us from showing it. The bug was fixed in a stable update to whatever release the bug was introduced in. Either way, I've just pushed changes to master documenting the additional options in the man page, since we should do that anyway. <snip> > Either way, the final script is less than beautiful: > http://pastebin.com/KmedZHsJ Yeah I'm not going to advocate sleep calls as part of the recommended Meld command line API. > I'm happy to report, though, that the script still performs correctly if > another meld instance is open before it runs (the new meld instance stays > active until its tab is closed). Right. Getting application-waiting stuff correct is genuinely difficult, and is one of the major headaches in 3.x. So having taken another look at this, I think that my earlier answer was just wrong, and creating the main tab as the last tab and is probably just a bug from the GtkApplication port. I've just pushed changes to current master to: * open the main (non --diff specified) comparison as the first tab * only auto-compare the first tab * only set labels on the first tab which I think gets us back to roughly what the pre-3.12 command line API was, and I *think* does what you want. I think these changes close this bug (though probably not the --label one, but I'll let you decide that). If current master doesn't do what you want, please do reopen this bug. (and I'm still open to larger scale command line changes, since they've been on the to-do list for forever)