Mercurial Отменить Слияние

есть сценарий, в котором мы непреднамеренно объединили именованную ветвь (ABC) в нашей default филиала.

hg rollback не является вариантом, потому что с тех пор было несколько коммитов.

есть ли способ отменить это?

12
branch mercurial

4 ответов

Если вы не опубликовали РЕПО публично, вы можете сделать это

hg clone -r (parent1 of bad merge) -r (parent2 of bad merge) old new

и удалить старый РЕПО.

4

вам понадобится расширение Mq. Если вы не включили его, сделайте это, добавив это в свой Mercurial.ini или .

[extensions]
hgext.mq=

если вы не знакомы с ним,расширение Mq давайте вы манипулировать историей. Хорошая новость в том, что это позволит нам исправить ваше РЕПО. Плохая новость в том, что любой, у кого есть клон испорченного РЕПО, должен будет клонировать его снова, потому что мы изменим историю.

сначала сделайте еще один клон твоего РЕПО для работы, чтобы мы ничего не испортили.

теперь найдите идентификатор ревизии набора изменений слияния (который слился default и ваша именованная ветвь). Записать его. Мы будем называть его changesetM. Теперь найдите идентификатор редакции следующего набора изменений. Записать его. Мы будем называть его changesetN.

как только у вас есть эти два идентификатора редакции, перейдите в командную строку и cd в свой РЕПО. Затем введите следующее, заменив changeset[M|N] С соответствующим идентификатор редакции.:

$ hg qimport -r changesetN:tip
  # This will add all of your changes since the merge to the queue
$ hg qpop -a
  # This pops them all out of your history.
$ hg strip changesetM
  # This removes the merge changeset.
$ hg update -C default
  # Make sure we're on the default branch
$ hg qpush -a
  # Take the changesets in the queue and push them back onto your history.
$ hg qfinish -a
  # Remove changesets from the queue and finalize them as normal changesets.

по сути, вы переназначаете новые наборы изменений поверх ветви по умолчанию, удаляя набор изменений слияния в процессе. Как только вы закончите, вам нужно будет перенести изменения в новый репозиторий на сервере, и ваши коллеги клонируют свежие копии.

наконец, если у вас есть какие-либо другие ртутные вопросы, также проверьте kiln.stackexchange.com.

обновление

я забыл упоминание: если кто-то основывал изменения на чем-то, что было только в другой ветви, возможно, что hg qpush -a не удастся. Вы увидите foo.txt.rej и foo.txt.orig файл, лежащий вокруг. К сожалению, тебе придется все исправить самому. Чтобы исправить это, откройте исходный файл, и .rej file и Выберите правильные изменения для слияния, сохраняя их в исходном файле. После того, как вы объединили его, используйте hg qrefresh обновить патч в новый, объединенный патч. Из их, вы должны быть возможность запуска hg qpush -a еще раз и продолжить. Если вы снова столкнетесь с той же ошибкой в другом патче, просто выполните тот же процесс.

8

сегодня я наткнулся на следующий сценарий:

@    changeset:   1728:5d703e1051d3
|\   parent:      1727:1a5f73b5edb4
| |  parent:      1720:65ddd0bde225
| |  user:        nn
| |  date:        Wed Feb 27 10:35:00 2013 +0100
| |  summary:     Merge with SomeBranch
| |
| o  changeset:   1727:1a5f73b5edb4
| |  user:        nn
| |  date:        Wed Feb 27 10:34:30 2013 +0100
| |  summary:     lorem ipsum
| |
[some more changesets]
| |
o |  changeset:   1720:65ddd0bde225
| |  branch:      SomeBranch
| |  user:        nn
| |  date:        Wed Feb 27 07:44:46 2013 +0100
| |  summary:     lorem ipsum

здесь SomeBranch не должны были быть объединены в по умолчанию. То, что мы сделали, чтобы решить эту проблему, было использовать с вот так:

hg backout --rev=1728 --parent=1727

это не отменить само слияние: глядя на график ветви (либо с журналом графика, либо в TortoiseHg), вы все равно увидите SomeBranch зайдя в по умолчанию at r1728. The результат слияния, однако, отменено, что означает, что набор изменений, содержащий backout (r1729 в моем случае), идентичен r1727.

3

1