Mercurial Undo Merge

Ако не сте публикували репото публично, можете да направите това

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

и изтрийте старото репо.

Ще ви трябва разширението 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 отново и да продължите. Ако попаднете на същата грешка отново при друга корекция, просто следвайте същия процес.

Днес попаднах на следния сценарий:

@    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 не трябваше да се обединява в default. Това, което направихме, за да разрешим това, беше да използваме командата backout с опцията parent така:

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

По този начин вие не отменяте самото сливане: Гледайки графика на клон (или с дневник на графика, или в TortoiseHg), пак ще видите SomeBranch, който влиза в по подразбиране при r1728. Резултатът от сливането обаче е отменен, което означава, че наборът от промени, съдържащ обратното (r1729 в ​​моя случай) е идентичен с r1727.