Avoir un scénario dans lequel nous avons involontairement fusionné une branche nommée (ABC) dans notre branche default.Mercurial Annuler Fusionner
hg rollback n'est pas une option car il y a eu quelques commits depuis.
Existe-t-il un moyen d'annuler cela?
Si vous publiez pas la pension publique, vous pouvez le faire
hg clone -r (parent1 of bad merge) -r (parent2 of bad merge) old new
et supprimer l'ancien repo.
Vous aurez besoin de l'extension Mq. Si vous ne l'avez pas activé, faites-le en l'ajoutant à votre fichier Mercurial.ini ou .hgrc.
[extensions]
hgext.mq=
Si vous n'êtes pas familier avec elle, vous manipuler l'histoire du Mq extension let. Les bonnes nouvelles sont, cela nous permettra de réparer votre repo. La mauvaise nouvelle est que tous ceux qui ont un clone du repo foiré devront le refaire, parce que nous changerons l'histoire. Tout d'abord, allez faire un autre clone de votre repo pour travailler, donc nous ne gâchons rien.
Maintenant, recherchez l'ID de révision de l'ensemble de modifications de fusion (qui a fusionné default et votre branche nommée). Écris le. Nous l'appellerons changesetM. Trouvez maintenant l'identifiant de révision du prochain changeset. Écris le. Nous l'appellerons changesetN. Une fois que vous avez ces deux ID de révision, rendez-vous sur votre invite de commande et entrez cd dans votre repo. Tapez ensuite le suivant, en remplaçant changeset[M|N] avec l'identifiant de révision appropriée .:
$ 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.
, vous êtes essentiellement rebasage les nouveaux changesets au-dessus de la branche par défaut, en supprimant la fusion de changeset dans le processus. Une fois que vous avez terminé, vous devez transférer les modifications dans un nouveau référentiel sur le serveur et demander à vos collègues de cloner des copies fraîches.
Enfin, si vous avez d'autres questions Mercurial, consultez aussi kiln.stackexchange.com.
MISE À JOUR
j'oublié de mentionner: Si quelqu'un a fondé des changements sur quelque chose qui est seulement dans l'autre branche, il est possible que hg qpush -a échouera. Vous verrez un fichier foo.txt.rej et foo.txt.orig. Malheureusement, vous devrez le réparer vous-même. Pour le réparer, ouvrez le fichier d'origine, le fichier .orig et le fichier .rej et choisissez les modifications appropriées pour fusionner, en les enregistrant dans le fichier d'origine. Une fois que vous l'avez fusionné, utilisez hg qrefresh pour mettre à jour ce correctif dans le nouveau correctif fusionné. De leur, vous devriez pouvoir courir hg qpush -a encore et continuer. Si vous rencontrez la même erreur sur un autre patch, suivez le même processus.
Je suis avec vous jusqu'à ce que hg qpush -a. Je reçois ce qui suit dans la console: l'application xxx.diff fichier de correction ----- Hunk # 1 ÉCHEC à 806 1 sur 1 hunks FAILED - l'enregistrement rejette "..." patch a échoué, impossible de continuer ... erreurs lors de l'application, veuillez corriger et actualiser 310.diff –
Voir la section mise à jour dans ma réponse. – tghw
Cela détruit l'historique, donc cela ne fonctionnera pas si l'erreur a été propagée. Voir: http://stackoverflow.com/questions/265944/backing-out-a-backwards-merge-on-mercurial –
Je suis tombé sur le scénario suivant aujourd'hui:
@ 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
Où SomeBranch ne doit pas avoir été fusionnées en par défaut. Ce que nous avons fait pour résoudre ce problème, était d'utiliser la commande backout avec l'option parent comme ceci:
hg backout --rev=1728 --parent=1727
Par cela, vous ne annuler la fusion elle-même: En regardant un graphique de branche (soit avec journal graphique ou dans TortoiseHg) vous verrez toujours SomeBranch entrer dans par défaut à r1728. Le résultat de la fusion est cependant annulé, ce qui signifie que le changeset contenant le backout (r1729 dans mon cas) est identique à r1727.
Est-ce que cela prend également en compte les drapeaux de fusion? – elzapp
Cela fonctionne ... merci! Maintenant, j'ai un problème restant: comment obtenir les changesets appliqués après la fusion incorrecte dans mon dépôt nouvellement cloné? –
@Steve Voir ma réponse. Vous devrez les "rebaser" sur la vieille tête. – tghw
backout ne peut pas annuler une fusion. – tghw