Пожалуйста, смотрите ответ ниже от Magras de La Mancha для лучшего решения с Mercurial 3.1. Ниже приведено более простое и наивное решение для более старых версий Mercurial.
Да, вам нужно настроить пользовательский инструмент слияния для вашего .hgtags файла. Mercurial не предоставляет какого-либо специального инструмента слияния для .hgtags, от него ожидают слияния вручную, используя обычный трехсторонний инструмент слияния.
Конфликты в файле .hgtags могут иметь два типа:
Глупые конфликты: Это ваша ситуация, и здесь нет никакого конфликта. То, что происходит, - то, что у одной ветви есть
f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
12e0fdbc57a0be78f0e817fd1d170a3615cd35da C
, а другая ветвь имеет
f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
979c049974485125e1f9357f6bbe9c1b548a64c3 D
Каждый тег относится только к одному набору изменений, поэтому здесь нет конфликта. Конечно, объединение должно быть объединением одного из двух файлов:
f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
12e0fdbc57a0be78f0e817fd1d170a3615cd35da C
979c049974485125e1f9357f6bbe9c1b548a64c3 D
Реальные конфликты: Там одна ветка имеет
f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
12e0fdbc57a0be78f0e817fd1d170a3615cd35da C
, а другая ветвь имеет
f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
979c049974485125e1f9357f6bbe9c1b548a64c3 C
Здесь есть реальный конфликт: hg tag C было сделано в обеих ветвях, но теги относятся к различным наборам изменений. Решение этой проблемы выполняется вручную.
Если вы можете гарантировать, что у вас будут только глупые конфликты и что у вас будет только один тег на набор изменений, тогда вы можете использовать
hg log -r "tagged()" --template "{node} {tags}\n" > .hgtags
для создания нового .hgtags файла. Главное, что Mercurial знает, как объединить теги внутри! Он делает это все время, когда у вас есть две головки с разными .hgtags файлами. Приведенный выше шаблон просто генерирует новый файл .hgtags на основе этого внутреннего слияния.
Если у вас может быть более одного тега на набор изменений, вышеописанное не сработает - все теги печатаются в одну строку, поэтому вы получаете тег foo bar вместо двух тегов foo и bar. Затем вы можете использовать этот файл стиля вместо:
changeset = "{tags}"
tag = "{node} {tag}\n"
Выводит одну строку на тег , а не набор изменений. Вы сохраняете этот стиль где-то и настраиваете инструмент слияния:
[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
Теперь у вас есть автоматическое слияние тегов. Есть несколько предостережений:
Три или более голов: Техника работает, только если у вас есть две головы на момент слияния. Если у вас три головы или более, удаленный тег может появиться снова. Если у вас есть главы X, Y и Z, а тег A удален в X, то Mercurial обычно может определить, что A удалено в целом. Он делает это на основе строки 000...0 A в файле .hgtags в X. Однако, если вы объедините X и Y, чтобы получить W, тогда предложенный подход не будет содержать такой строки 000...0 A. Определение A от Z теперь внезапно вступит в силу и вновь введет A.
Реальные конфликты: Если у вас есть реальные конфликты в .hgtags, то вышеуказанный метод автоматически выберет для вас тег из самой последней головы . Инструмент слияния в основном сохраняет hg tags в .hgtags, а поведение hg tags с несколькими головками объяснено в вики . Так как hg tags безоговорочно читает и молча объединяет файл .hgtags со всех голов, мы ничего не можем с этим поделать с этим простым подходом. Чтобы справиться с этим, потребуется большой скрипт, который читает два файла .hgtags и обнаруживает конфликт.