Важным фактором, почему вы получили трехстороннее слияние, является то, что ваш контекст слишком искусственный, и я доберусь до этого.
Если я возьму текстовый файл из 50 строк и изменим другую частьи вносить каждое изменение, мне не придется разрешать конфликты.И я имею в виду, что у меня есть 4 набора изменений: версия 0 добавляет файл, версии 1, 2 и 3, каждая из которых изменяет одну область файла: начало, середину или конец.
В этой ситуации, когдаЯ делаю hg backout 2
, он делает реверс 2-й версии и объединяет эти изменения с моим рабочим каталогом, и когда я фиксирую, график является линейным:
@ backout 2
|
o 3
|
o 2
|
o 1
|
o initial
Если я вместо этого hg backout 2 --merge
, онавтоматически фиксирует возврат как дочерний элемент ревизии, которую он отклоняет, а затем объединяет ее с подсказкой, создавая разветвленный граф после того, как я фиксирую слияние:
@ merge
|\
| o backout 2
| |
o | 3
|/
o 2
|
o 1
|
o initial
В обеих ситуациях я не делалдолжны сделать любое 3-х стороннее слияние.Причина, по которой вы автоматически не получаете
init
1
3
и вместо этого должны выполнять трехстороннее слияние, заключается в том, что изменения слишком близки друг к другу.Контекст и изменения в каждом наборе изменений полностью перекрываются (по умолчанию количество строк контекста для блока diff составляет 3 строки, что охватывает весь файл, все еще содержащийся в вашем 4-м наборе изменений).
Аналогичный пример, если вы имели3 набора изменений, каждый из которых изменил одну и ту же строку.Если вы отступили от среднего изменения, как вы делаете здесь, вы все равно получили бы трехстороннее слияние, которое вам, вероятно, придется вручную редактировать, чтобы получить правильное значение.
Кстати, поведение сделалоизменение в 1.7, подтвержденное hg help backout
:
До версии 1.7 поведение без --merge было эквивалентно указанию --merge, за которым следует «hg update --clean».отменить слияние и оставить ребенка REV в качестве главы для отдельного слияния.
Однако я не думаю, что это именно то, что вы подозревали.