Изменилось ли поведение `hg backout` с момента написания книги hg?

Question

Я создал новый репозиторий test-backout и добавил в него новый файл file. Затем я сделал 4 коммита, каждый раз добавляя номер коммита к file, используя

echo [manually entered number] >> file
hg commit -m '[manually entered number]'

В действительности файл имел:

init
1
2
3

В соответствии с книгой hg, если я запускаю hg backout --merge 2, у меня должно быть:

init
1
3

но вместо этого он не может слиться и открывает мой difftool (vimdiff), и я получаю 3 варианта:

init          | init          | init
1             | 1             |
2             |               |
3             |               |

Сначала я попробовал с опцией --merge, затем снова без нее. Теперь у меня вопрос, есть ли еще способ получить:

init
1
3

я просто ошибся или что-то упустил, или я застрял с этими опциями?

Answer 1

Важным фактором, почему вы получили трехстороннее слияние, является то, что ваш контекст слишком искусственный, и я доберусь до этого.

Если я возьму текстовый файл из 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 в качестве главы для отдельного слияния.

Однако я не думаю, что это именно то, что вы подозревали.