Изменилось ли поведение `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 набора изменений: rev 0 добавляет файл, rev 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 в качестве главы для слияния отдельно.

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