Mercurial Отменить слияние - PullRequest
13 голосов
/ 30 июня 2010

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

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

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

Ответы [ 4 ]

8 голосов
/ 30 июня 2010

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

[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.

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

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

ОБНОВЛЕНИЕ

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

4 голосов
/ 30 июня 2010

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

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

и удалить старое репо.

3 голосов
/ 27 февраля 2013

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

@    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 не должно быть объединено с по умолчанию . Чтобы решить эту проблему, мы использовали команду backout с параметром parent следующим образом:

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

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

...