Question

I have a script running some Mercurial commands in non-interactive mode on a build server. One of the commands merges two branches and there is always a conflict in the .hgtags file during the merge because of the way the build scripts are set up.

How can I force Mercurial to always merge the .hgtags file using changes from both files, first from one, then from the other?

For example, if I the files to merge were

A
B
C

and

A
B
D

I would like the result to be

A
B
C
D

I am guessing I will need a custom merge tool. What tool provides this functionality?

Answer 1

Please see the answer below by Magras de La Mancha for better solution with Mercurial 3.1. The below is a simpler and more naive solution for older versions of Mercurial.

---

Yes, you need to configure a custom merge tool for your .hgtags file. Mercurial doesn’t provide any special merge tool for .hgtags, you’re expected to merge it by hand using your normal three-way merge tool.

Conflicts in the .hgtags file can have two types:

• Silly conflicts: This is the situation you have and there is not really a conflict here. What happens is that one branch has

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  12e0fdbc57a0be78f0e817fd1d170a3615cd35da C
  

  and the other branch has

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  979c049974485125e1f9357f6bbe9c1b548a64c3 D
  

  Each tag refers to exactly one changeset, so there’s no conflict here. The merge should of course be the union on of the two files:

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  12e0fdbc57a0be78f0e817fd1d170a3615cd35da C
  979c049974485125e1f9357f6bbe9c1b548a64c3 D
  

• Real conflicts: There one branch has

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  12e0fdbc57a0be78f0e817fd1d170a3615cd35da C
  

  and the other branch has

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  979c049974485125e1f9357f6bbe9c1b548a64c3 C
  

  There is a real conflict here: hg tag C was done on both branches, but the tags refer to different changesets. Resolving this is a manual task.

If you can guarantee that you’ll only have silly conflicts and that you only have one tag per changeset, then you can use

hg log -r "tagged()" --template "{node} {tags}\n" > .hgtags

to generate a new .hgtags file. The key insight is that Mercurial knows how to merge tags internally! It does this all the time when you have two heads with different .hgtags files. The above template simply generates a new .hgtags file based on this internal merge.

If you might have more than one tag per changeset, then the above wont work — all the tags are printed on one line so you get a tag foo bar instead of two tags foo and bar. You can then use this style file instead:

changeset = "{tags}"
tag = "{node} {tag}\n"

It outputs one line per tag, not changeset. You save this style somewhere and configure a merge tool:

[merge-tools]
hgtags.executable = hg
hgtags.args = log -r "tagged()" --style ~/tmp/tags-style > $output
hgtags.premerge = False
hgtags.priority = -1000

[merge-patterns]
.hgtags = hgtags

You now have automatic tag merges. There are some caveats:

1. Three or more heads: The technique only works if you have two heads at the time of merging. If you have three heads or more, it’s possible for a deleted tag to re-appear. If you have heads X, Y, and Z, and the tag A is deleted in X, then Mercurial is normally able to figure out that A is deleted overall. It does this based on a 000...0 A line in the .hgtags file in X. However, if you merge X and Y to get W, then the approach suggested will not contain any such 000...0 A line. The definition of A from Z will now suddenly take effect and re-introduce A.

2. Real conflicts: If you have real conflicts in .hgtags, then the above method will silently pick the tag from the most recent head for you. The merge tool basically saves hg tags in .hgtags, and the behavior of hg tags with multiple heads is explained in the wiki. Since hg tags unconditionally reads and silently merges the .hgtags file from all heads, there’s nothing we can do about it with this simple approach. Dealing with this would require a bigger script that reads the two .hgtags files and detects the conflict.