How to automatically merge .hgtags in Mercurial?

问题

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?

回答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:

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.
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.

回答2:

Mercurial 3.1 (2014-08-01) introduced internal:tagmerge. It's marked as experimental so be careful. Here is preamble from changeset (you can find more details about algorithm if you follow the link):

Add a new internal:tagmerge merge tool which implements an automatic merge algorithm for mercurial's tag files

The tagmerge algorithm is able to resolve most merge conflicts that currently would trigger a .hgtags merge conflict. The only case that it does not (and cannot) handle is that in which two tags point to different revisions on each merge parent and their corresponding tag histories have the same rank (i.e. the same length). In all other cases the merge algorithm will choose the revision belonging to the parent with the highest ranked tag history. The merged tag history is the combination of both tag histories (special care is taken to try to combine common tag histories where possible).

The algorithm also handles cases in which tags have been manually removed from the .hgtags file and other similar corner cases.

In addition to actually merging the tags from two parents, taking into account the base, the algorithm also tries to minimize the difference between the merged tag file and the first parent's tag file (i.e. it tries to make the merged tag order as as similar as possible to the first parent's tag file order).

tagmerge works only with tag files, so to use it you should set merge-patterns. To do this on per command basis use --config option:

hg merge -r REV --config merge-patterns..hgtags=internal:tagmerge

Or to do this on per repository basis add to your repo config .hg/hgrc this:

[merge-patterns]
.hgtags=internal:tagmerge

回答3:

You don't actually need to merge the .hgtags file. It can be different on different branches and Mercurial will correctly list all tags across all branches.

We use the merge-patterns configuration option to tell Mercurial to use the local branch when doing merges of .hgtags. Add the following to your repository's hgrc file:

 [merge-patterns]
 .hgtags = internal:local

When doing a merge involving the .hgtags file, .hgtags will show as modified, but not be changed.

回答4:

You can not automatically resolve merge-conflicts by performing unattended merge. Without merge (i.e. selecting "only my" or "only other") it will work.

I'm afraid, you have badly planned workflow - build-server must not perform any actions, which modify sources. It's task for human and human's choice.

But I suppose, exact data inside .hgtags have to value for build-server (it uses own clone, not populated to anybody, I hope?!), thus you can define any merge-policy in command and have (bad, with data-loss) .hgtags merged

BTW, "first from one, then from the other" in any language, using only formal logic, for pair