Отметить изменения как уже слитые или намеренно проигнорированные с помощью hg pull / push / merge / graft?

Question

Я перехожу к Mercurial из Subversion, где я привык использовать svnmerge.py для отслеживания изменений, которые уже были объединены или заблокированы от объединения:

# Mark change 123 as having already been merged; it will not be merged again, even if a range
# that contains it is subsequently specified.
svnmerge.py merge -M -r123
#
# Block change 326 from being considered for merges.
svnmerge.py merge -X -r326
#
# Show changes that are available for merging from the source branch.
svnmerge.py avail
#
# Do a catchall merge of the remaining changes.  Neither change 123 nor change 326 will be
# considered for merging.
svnmerge.py merge

Iхочу иметь возможность сделать что-то похожее для hg pull / push / merge / graft, так что если я знаю, что никогда не хочу объединять данное изменение, я могу просто заблокировать это для рассмотрения, делая последующий сбор вишни, объединение и т. д.., в более огненное дело и забыть.Я много гуглил, но не нашел способа сделать это.

Похоже, что нет возможности просмотреть список еще не внесенных изменений.

КакЯ часто прибираюсь после других разработчиков и помогаю им в их слияниях, очень полезно иметь возможность делать такие вещи, которые можно было бы считать «обратным сбором вишни»;т. е. помечать изменения, которые вы НЕ хотите объединять, а затем выполнять массовое объединение остатка.

Answer 1

Системы на основе DAG, такие как Mercurial и Git, представляют собой все или ничего: когда вы объединяете две ветви, вы делаете трехстороннее объединение общего предка и двух ветвей.

Трехстороннее объединение только касается финальной стадии каждой ветви.Например, не имеет значения, внесете ли вы изменения в 10 или 1000 шагов - результат объединения будет таким же.

Это означает, что единственный способ игнорировать набор изменений - это вернуть его дослияние:

$ hg backout BAD

Это отменит набор изменений в ветви, создавая впечатление, что оно никогда не было сделано с точки зрения трехстороннего слияния.

Если у вас есть целая ветвьчто вы хотите объединить, но игнорировать, тогда вы можете сделать фиктивное объединение :

$ hg merge --tool internal:local --non-interactive
$ hg revert --all --rev .

, которое проходит через объединение, но возвращается к старому состоянию перед фиксацией.

---

Лучший совет, который я могу вам дать, - это структурировать рабочий процесс так, чтобы вышеуказанные отказы не были необходимы.Это означает исправление ошибки в самой старой аппликативной ветке .Если при создании функции X обнаружена ошибка, используйте hg bisect, чтобы выяснить, когда эта ошибка появилась.Теперь обновите обратно до самой старой ветки, где вы все еще хотите исправить ошибку:

$ hg update 2.0
# fix bug
$ hg commit -m "Fixed issue-123"

, затем объедините исправление со всеми более поздними ветками:

$ hg update 2.1
$ hg merge 2.0
$ hg commit -m "Merge with 2.0 to get bugfix for issue-123"

$ hg update 2.2
$ hg merge 2.1
$ hg commit -m "Merge with 2.1 to get bugfix for issue-123"

Если исправление больше не применяется,тогда вы должны все еще объединить , но выбросить несвязанные изменения:

$ hg update 3.0
$ hg merge 2.2 --tool internal:local --non-interactive
$ hg revert --all --rev .
$ hg commit -m "Dummy merge with 2.2"

Это гарантирует, что вы всегда можете использовать

$ hg log -r "::2.2 - ::3.0"

для просмотра наборов изменений на 2.2ветвь, которая еще не была объединена в 3.0.