Search code examples
version-controlmercurialmergedvcsthree-way-merge

How do I specify a merge-base to use in a 'hg merge'


I'm trying to do a complicated merge in a complicated hg repository. I'm not happy with the "newest shared ancestor" that Mercurial chooses to use as the "base" to perform the merge.

I'd like to specify a specific commit of my own choice to use as base.

Is this possible, and if so, how?


Solution

  • Mercurial 3.0: You can now select the ancestor to use as a merge base. You do that by setting merge.preferancestor. Mercurial will tell you about it when this makes sense. With the example below, you would see:

    $ hg merge
    note: using eb49ad46fd72 as ancestor of 333411d2f751 and 7d1f71140c74
          alternatively, use --config merge.preferancestor=fdf4b78f5292
    merging x
    0 files updated, 1 files merged, 0 files removed, 0 files unresolved
    (branch merge, don't forget to commit)
    

    Mercurial before version 3.0: Lazy Badger is correct that you cannot pick the ancestor picked by Mercurial when using it from the command line. However, you can do it internally and it's not too difficult to write an extension for this:

    from mercurial import extensions, commands, scmutil
    from mercurial import merge as mergemod
    
    saved_ancestor = None
    
    def update(orig, repo, node, branchmerge, force, partial, ancestor=None):
        if saved_ancestor:
            ancestor = scmutil.revsingle(repo, saved_ancestor).node()
        return orig(repo, node, branchmerge, force, partial, ancestor)
    
    def merge(orig, ui, repo, node=None, **opts):
        global saved_ancestor
        saved_ancestor = opts.get('ancestor')
        return orig(ui, repo, node, **opts)
    
    def extsetup(ui):
        extensions.wrapfunction(mergemod, 'update', update)
        entry = extensions.wrapcommand(commands.table, 'merge', merge)
        entry[1].append(('', 'ancestor', '', 'override ancestor', 'REV'))
    

    Put this in a file and load the extension. You can now use

    hg merge --ancestor X
    

    to override the normal ancestor. As you've found out, this does make a difference if there are several possible ancestors. That situation arises if you have criss-cross merges. You can create such a case with these commands:

    hg init; echo a > x; hg commit -A -m a x
    hg update 0; echo b >> x; hg commit -m b
    hg update 0; echo c >> x; hg commit -m c
    hg update 1; hg merge --tool internal:local 2; echo c >> x; hg commit -m bc
    hg update 2; hg merge --tool internal:local 1; echo b >> x; hg commit -m cb
    

    The graph looks like this:

    @    changeset: 4:333411d2f751
    |\
    +---o  changeset: 3:7d1f71140c74
    | |/
    | o  changeset: 2:fdf4b78f5292
    | |
    o |  changeset: 1:eb49ad46fd72
    |/
    o  changeset: 0:e72ddea4d238
    

    If you merge normally you get changeset eb49ad46fd72 as the ancestor and the file x contains:

    a
    c
    b
    c
    

    If you instead use hg merge --ancestor 2 you get a different result:

    a
    b
    c
    b
    

    In both cases, my KDiff3 were able to handle the merge automatically without reporting any conflicts. If I use the "recursive" merge strategy and pick e72ddea4d238 as the ancestor, then I'm presented with a sensible conflict. Git uses the recursive merge strategy by default.