by Myk Melez | Mozilla

Merging with Mercurial 1.0 and Meld

In an earlier post, I described my experience merging changes with Mercurial 0.9.5 and Meld 1.1.5.1 on Ubuntu 8.04.

Things have changed in Ubuntu 8.10, which ships Mercurial 1.0.1. Now Meld displays your version of the file on the left, the other version on the right, and the base version (from which yours and the other are descended) in the middle.

Here it is handling the Merging conflicting changes example from the hg book:

Your job is to reconcile the conflicts between your version on the left and the other version on the right, turning your version on the left into the result of the reconciliation, which you then save to your working directory.

I understand why it can be useful to show the base version, and I think it’s ok to use the same pane to show both your version and the final result (although kdiff3 provides a fourth pane beneath these three for the latter, which seems better).

But I don’t understand why the base version is in the middle, given that one’s primary task in this situation is to compare the differences between the two versions on either side of the window, copying changes from one to the other as needed. Putting another file in the middle just gets in the way of that process (which is presumably why kdiff3 puts the base version on the left and your version in the middle according to the screenshot in the aforementioned example in the hg book).

In fact, I frequently find myself starting a merge by copying the other version of the file into the base version in its entirety. That destroys my ability to refer to the base version, but it places the other version and my version side by side, at which point it’s much easier to compare the two and edit my version accordingly:

But maybe I’m missing the point or misusing the tool, and there’s some valid reason for the way Mercurial uses Meld. Can someone tell me what it is?

 

Myk Melez

Myk is a Principal Software Architect and in-house entrepreneur at Mozilla. A Mozillian since 1999, he's contributed to the Web App Developer Initiative, PluotSorbet, Open Web Apps, Firefox OS Simulator, Jetpack, Raindrop, Snowl, Personas, Firefox, Thunderbird, and Bugzilla. He's just a cook. He's all out of bubblegum.

 

10 thoughts on “Merging with Mercurial 1.0 and Meld”

  1. Dude. You’re not using hg 1.1.

    Do yourself a favor and upgrade now. Then add “[extensions] color =” to your ~/.hgrc, do a diff, and thank me for the beauty of colorized diffs (with trailing whitespace highlighting no less!).

    Colorized diffs were by themselves enough to make the upgrade worthwhile for me, but I hear mq also got some needed bugfixes. You really should upgrade, 1.0 is oooold.

  2. Jeff: Dude, I’m getting colorized diffs on Mercurial 1.0 via the extdiff extension.

    I don’t yet use mq, so that’s not an issue. But I do want to upgrade to 1.1 for rebase, which seems super useful.

    I just hate manually maintaining software, so I’d much rather get it from my distribution’s automatically-managed software archives. Which means waiting until Jaunty Jackalope (Ubuntu 9.04) is released, and then waiting until VMware Fusion, in which I run the OS, supports that version of it.

    That could be months, so perhaps I should upgrade manually.

  3. Isn’t that a matter of setting meld.args in [merge-tools]?

    I’m surprised the defaults for meld and kdiff3 differ in hg.

  4. For comparison, I believe Araxis Merge shows you the base version in the middle, but then has an “auto-merge” feature to merge as many changes from the two sides as possible, while Perforce has the three “originals” in the top third of the screen, with the “result” taking up the bulk of the display (I forget offhand whether it automerges or not). There are occasions where it’s helpful to see both diffs.

  5. I gave up on meld after my first experience with it and switched to kdiff3, despite not using KDE. It is tons better. Its merge algorithm seems stronger, such that it automatically handles a lot of things for me, and the UI is just easier to understand, and quicker for me to get the right changes in the right place.

  6. M.J.G.: indeed, the following addition to ~/.hgrc creates a more reasonable arrangement (which is identical to the one Mercurial creates by default in kdiff3):

    [merge-tools]
    meld.args = $base $local $other

    Ted: Yeah, I should probably try kdiff3. I just don’t want to install a whole other desktop environment for it (nor install software manually, and it looks like Ubuntu no longer packages kdiff3).

  7. Hi, thanks for this post, information on hg merge+meld are rare.
    I'm currently using Mercurial 1.4 on Debian squeeze/testing and it seems that it behaves differently: the local file (result of the merge) is located on the left panel.
    As this post (or the previous) appears high on a web search, can you please indicate (if you're ok with me) this correction?

  9. Now if they can just get meld to return an actual error code if the merge fails (ie not saved) then meld + mercurial would be great

  10. Meld just isn't working for me. After what I thought must be a simple merge (though with a conflict), it left me with a whole bunch of stuff to review, and I had no idea what was going on.

    Instead, I just use the "merge" command, and fix things up in my favourite editor if there are conflicts. In the above case, there was only a single conflict that I had to review, and that was very quickly resolved. Now, what would be useful is to show just the conflict in Meld. But I don't see how to do that easily.

    BTW, if you're using Ubuntu, you'll need to install the "rcs" package to get the "merge" command.

Comments are closed.