merge conflict with tags is surprising ?

[Greg Ward]

On Wed, Aug 19, 2009 at 2:11 PM, rupert.thurner<rupert.thurner at gmail.com> wrote:
> when working with branches we managed to produce a merge conflict with
> tags, as .hgtags is in the working copy and therefor differs. so if
> one adds a tag 5.0.1 to one branch, and somebody else adds the tag
> 5.0.2 to another branch for a different changeset it produces a merge
> conflict.

Yes.  This is an (almost) unavoidable consequence of the way Mercurial
implements tags.

> would it be compatible with mercurial's philosophy to implement
> something which teaches mercurial about its own tags in such cases?

IMHO yes.  Many months ago, before I really understood things well, I
hacked together a script called hgmergetags.  I now understand that
it's subtly incorrect for certain obscure cases.  (In particular, the
order of lines in .hgtags *is* important, and hgmergetags does not
preseve that order.  Oops.)

Anyways, I'll attach the script.  Here is how I configure it:

"""
[merge-patterns]
# XXX hgmergetags is wrong: it munges order of .hgtags, which is
# important
.hgtags = hgmergetags

[merge-tools]
hgmergetags.args = $local $base $other > $output
hgmergetags.priority = -10
"""

The priority is important: you don't want to run hgmergetags on any
files *other* than .hgtags, and giving it a low priority does that.

Greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hgmergetags
Type: application/octet-stream
Size: 6281 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20090819/2a464b0e/attachment-0003.obj>