After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 699030 - in conflict merge view, put LOCAL on left to match merge marker direction
in conflict merge view, put LOCAL on left to match merge marker direction
Status: RESOLVED FIXED
Product: meld
Classification: Other
Component: version
git master
Other Linux
: Normal normal
: ---
Assigned To: meld-maint
meld-maint
Depends on:
Blocks:
 
 
Reported: 2013-04-27 12:23 UTC by Adam Dingle
Modified: 2014-04-24 23:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Adam Dingle 2013-04-27 12:23:21 UTC
Meld's conflict merge view currently displays three panes in this order:

REMOTE, MERGED, LOCAL

With git at least, the MERGED pane contains conflict markers which look like this:

<<<<<<< HEAD
foo
bar
=======
baz
>>>>>>>

I think it's slightly confusing that the HEAD marker looks like an arrow pointing left, but the LOCAL pane which contains the HEAD revision is actually on the right.  I think it would be nicer to display the panes in the order

LOCAL, MERGED, REMOTE

so the conflict markers would appear to point in the right direction.
Comment 1 Adam Dingle 2013-04-27 19:01:37 UTC
Another benefit is that this would match the order in which these files are displayed when using git mergetool; it would be nice to be consistent with that.
Comment 2 Kai Willadsen 2013-07-20 21:14:33 UTC
Given that this has been this way forever in Meld, I really can't just change it without a revert option... while I'd love to, users will just have too much built-up habit there.

I've added an option to the VC preferences pane that defines whether local is on the left or right. Default is right, because that's old Meld behaviour. I imagine that a gtk3 port will switch the default and/or remove the option entirely.

Thanks for the bug report.
Comment 3 Adam Dingle 2013-07-22 00:15:36 UTC
Awesome - thanks!
Comment 4 Adam Dingle 2013-07-30 13:24:05 UTC
I've found that when this new option is "Left is local, right is remote" and I double click a modified file in version control view, Meld displays the new version of the file on the left and the old version on the right.  That's unexpected and confusing, so it effectively makes this new option unusable for me.

I originally filed this bug with only the conflict merge view in mind - perhaps this new option should affect only that.  Reopening.
Comment 5 Kai Willadsen 2013-08-01 20:40:34 UTC
(In reply to comment #4)
> I've found that when this new option is "Left is local, right is remote" and I
> double click a modified file in version control view, Meld displays the new
> version of the file on the left and the old version on the right.  That's
> unexpected and confusing, so it effectively makes this new option unusable for
> me.

Yup! In fact, I should probably change the options to "Left is local, right is remote" and "Left is old, right is new"... except that that's not always totally accurate.

> I originally filed this bug with only the conflict merge view in mind - perhaps
> this new option should affect only that.  Reopening.

In that case, we'd need a second option. The Left-is-local thing is an issue for other users independent of the merge view. I'll think on this.
Comment 6 Kai Willadsen 2014-04-23 22:06:55 UTC
There's now a new option in the version control preferences pane for order when merging. You can now have two-pane left-is-remote and three-pane local/merge/remote ordering together, which I think makes the most sense for Git users. (This does make rebase look weird, but then... rebase.)

Thanks for the bug report.
Comment 7 Adam Dingle 2014-04-24 23:20:33 UTC
Fantastic - thanks!