Подтвердить что ты не робот

Meruurial Undo Merge

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

Вам понадобится расширение 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.

UPDATE

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

Ответ 3

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

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