Change order of lines in .hgtags to alleviate merge conflicts?

[Martin Geisler]

Matt Mackall <mpm at selenic.com> writes:

> On Mon, 2011-04-04 at 09:25 -0400, Greg Ward wrote:
>> On 03 April 2011, Martin Geisler said:
>> > Instead of sorting the lines as you suggest, I think we should let
>> > Mercurial merge the .hgtags files itself, probably using the algorithm
>> > it already uses when merging the .hgtags files read from different
>> > heads. So if I do
>> 
>> Hmmmm.  Will that work?  The tag-reading code deliberately discards
>> information in order to establish a mapping from tag to changeset ID.
>> Is that safe to do when merging .hgtags from different branches? You'd
>> lose all the implicit history of how tag 'foo' was moved then deleted
>> then recreated.  But maybe that doesn't matter.
>
> You definitely don't want to discard/compress tag information during a
> merge. Because as soon as you merge with a third head, you're going to
> need that info again.

I was not so much thinking of throwing away information -- I was more
thinking of accumulating it.

The algorithm in tags.py is a bit fuzzy for me, but right now the
.hgtags files are read from each head from oldest to youngest and tag
information is accumulated.

After merging two heads the new .hgtags file should contain the same
information as the two old .hgtags files. If the heads were read in
order A, B before, then I think

  $ hg cat -r A .hgtags > .hgtags
  $ hg cat -r B .hgtags >> .hgtags
  $ hg commit -m merge

would make Mercurial read in the same information after the merge as
before. Tags that are simply defined twice after the merge can be
reduced to a single line -- tags that are both deleted and reintorduced
will probably require more fancy merge machinery.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/