Merge tool should offer "manual resolve"

Issue #2073 resolved
abudden
created an issue

When merging branches in TortoiseHG, there are almost always three possibilities for how I want to do the merge:

  1. Automatic - I know that the changes in the two branches are completely separate and I expect that one tool or other will be able to do the merge correctly.

  2. Manual - I either don't know how the changes relate or I know there are likely to be conflicts and I want to start up Beyond Compare and go through the conflicts manually.

  3. Pick one - I know the changes in one branch are irrelevant or it's a auto-incrementing build number file or something like that and I just use "Take Local" or "Take Other".

The "Take Local" and "Take Other" options are great, but the other options are "Mercurial Resolve" and "Tool Resolve". "Mercurial Resolve" works brilliantly for case 1, but in case 2, "Tool Resolve" doesn't always do what I expect. If Beyond Compare thinks the changes are sufficiently separated it will auto-merge them. I pretty much never want it to do this. Okay, the changes are in separate bits of the file so it looks easy, but if they relate to the way a common function is called (or incompatible fixes for the same issue) there may well be conflicts that aren't apparent: this is why I chose "Tool Resolve" in the first place.

I can, of course, use the three-way diff button after Beyond Compare does the auto-merge, but in our department we've had quite a lot of incorrect merges as a result of this. The reason is that if it's a manual merge you get a different layout of the four files (base, local, other and result) to the layout with the three-way diff (in the three-way diff you don't get all four files: only local other and result), so it's easy to get confused and save the wrong thing.

I don't care whether the auto conflict resolution is done by Mercurial or Beyond Compare. I care whether the conflict resolution is automatic or manual.

Comments (4)

  1. Adrian Buehlmann

    Do you use Beyond Compare 3? I assume you are on Windows.

    I don't use BeyondCompare myself, but I see that TortoiseHg installs the file MergeTools.rc in "C:\Program Files\TortoiseHg\hgrc.d", which contains (partial quote):

    [merge-tools]
    ; Windows version of BeyondCompare 3
    beyondcompare3.priority=-1
    beyondcompare3.args=$local $other $base /mergeoutput=$output /ro /lefttitle=parent1 /centertitle=base /righttitle=parent2 /outputtitle=merged /automerge /reviewconflicts /solo
    beyondcompare3.premerge=False
    beyondcompare3.regkey=Software\Scooter Software\Beyond Compare 3
    beyondcompare3.regkeyalt=Software\Wow6432Node\Scooter Software\Beyond Compare 3
    beyondcompare3.regname=ExePath
    beyondcompare3.gui=True
    beyondcompare3.diffargs=/lro /lefttitle='$plabel1' /righttitle='$clabel' /solo /expandall $parent $child
    beyondcompare3.diff3args=$parent1 $parent2 $child /lefttitle='$plabel1' /centertitle='$clabel' /righttitle='$plabel2' /solo /ro
    beyondcompare3.dirdiff=True
    

    Looking at http://www.scootersoftware.com/help/index.html?command_line_reference.html it says about the /automerge option: "Automatically merges files without user interaction unless conflicts are found."

    I think you should be able to override that setting by including a [merge-tools] section in your personal mercurial.ini that has

    beyondcompare3.args=$local $other $base /mergeoutput=$output /ro /lefttitle=parent1 /centertitle=base /righttitle=parent2 /outputtitle=merged /reviewconflicts /solo

    (note that the /automerge option is *not* set in the overriding beyondcompare3.args).

    Please don't edit the MergeTools.rc file in C:\Program Files\TortoiseHg\hgrc.d. That file is not supposed to be edited. If you do, your edits will most likely be wiped on the next program update / install / uninstall.

    See http://selenic.com/repo/hg/help/config for the merge-tools config options.

    The mercurial command:

    hg debugconfig --debug

    might also be helpful, as it shows what config setting is coming from what config file exactly (it even shows the line number of each setting).

  2. abudden reporter

    Thank you: that sounds like a good work-around in the short term - I'll test it later on today.

    I still think this is an important thing to look at. This causes a lot of users in my department a lot of problems and it would be a pain to have to install custom mercurial.ini files on every user's desktop and laptop (especially since there are several desktops that are used by multiple people and each user will have a different mercurial.ini).

    Is it a common requirement for TortoiseHg users to want to auto-merge with something other than the built-in merge algorithm?

  3. Adrian Buehlmann

    I don't know what the exact thinking was when that install hgrc.d was written as it is now. I think Steve (who happens to also be the TortoiseHg project lead as you probably know) is the expert on such merge tool questions. He isn't that active anymore though (I think he's pretty busy and possibly still on holiday right now, that's why the current overdue TortoiseHg release is behind the recent August 1st Mercurial release).

    I must say though that I had similar user experience myself what you describe above (not with Beyond Compare exactly, but I had similar feelings with how Kdiff3 is started). So perhaps there could be made an argument to change the defaults in the install hgrc.d. But then we risk that other users get annoyed by changing the default. But might be used to how things are now.

    Perhaps you could start a discussion on the developer mailing list https://groups.google.com/forum/?fromgroups#!forum/thg-dev

    I think Steve is still reading there, but he might have a rather longish latency in responding currently (1 week).

    I haven't used it myself, but perhaps the https://bitbucket.org/aragost/projrc extension might be useful to you. No matter what defaults are chosen on the TortoiseHg project level, we can't possibly make everyone happy with the defaults anyway.

  4. Log in to comment