Mercurial: Puis-je renommer une succursale?


205

Nous avons maintenant une branche "stiging", où "staging" semble être un ajustement sémantique bien meilleur. Quelle est la bonne stratégie pour gérer cela?

Réponses:


224

Mettez à jour la stigingbranche et créez-en une nouvelle. Fermez ensuite l'ancienne branche.

En résumé:

hg update stiging
hg branch staging
hg commit -m"Changing stiging branch to staging."
hg update stiging
hg commit --close-branch -m"This was a typo; use staging instead."
hg push --new-branch

1
C'est la meilleure façon de le faire que j'ai trouvée. La fermeture de la branche empêche les autres de l'utiliser accidentellement car elle n'apparaît pas dans la sortie des "branches hg". Il vous permet toujours d'y accéder plus tard si vous connaissez le nom.
Ustensile

2
Mercurial permettra-t-il de réutiliser le nom d'une succursale fermée? C'est-à-dire, si vous avez une branche v3, pouvez-vous utiliser la technique ci-dessus pour la renommer en v4 et ensuite dériver une nouvelle branche v3 malgré avoir laissé derrière elle une v3 fermée?
Joshua Goldberg

4
@JoshuaGoldberg, 3noch a tort. Mercurial va vous permettre de réutiliser le nom d'une branche fermée si vous utilisez --force. Par exemple: hg branch --force v3. Cela se traduira par une hg update v3mise à jour vers la nouvelle v3branche, comme vous le vouliez.
Gili

2
a confirmé le commentaire de @ Gili avec la branche d'aide hg: "--force définir le nom de la branche même s'il masque une branche existante"
Joshua Goldberg

7
Si vous fermez stigingavant de vous bifurquer, vous n'obtenez pas une "extrémité lâche"
max.mustermann

60

Pour les futurs lecteurs: Avec l' rebaseextension, vous pouvez créer une nouvelle branche avec le même parent que stiginget y déplacer tout l'historique de la branche, comme ceci:

hg update -r "parents(min(branch('stiging')))"
hg branch staging
hg commit
hg rebase --source "min(branch('stiging'))" --dest staging

Cela suppose qu'il stigingn'a qu'un seul parent. Bien sûr, vous pouvez simplement utiliser des numéros de révision explicites à la place.

Note 1: Si la branche stigingcomprend des fusions avec d' autres branches, je pense que cela va les préserver, aussi longtemps que staginget stigingavoir le même parent. Mais je reverrais certainement.

Remarque 2: puisque cela modifie l'historique, l'ancienne branche ne disparaîtra pas simplement des référentiels clonés (voir la rebasedocumentation). À moins que tout le monde ne puisse cloner à nouveau, cela pourrait ne pas être une solution très pratique pour un grand groupe.

Note3 / Edit (gracieuseté de @JasonRCoombs): Maintenant que les phases sont standard dans mercurial, rebaserefusera de modifier les changesets qui ont déjà été poussés. Soit le tromper en changeant la phase en brouillon (avec hg phases), soit laisser l'ancienne branche rester où elle est, et juste faire une copie correctement nommée (par exemple, avec `hg rebase --keep ').


+1 pour les petites équipes où vous pouvez forcer les utilisateurs à cloner, c'est une bonne idée - ou utilisez à la hg convertplace.
hochl

5
Avec les dernières versions de Mercurial, la commande de rebase échouera avec "impossible de rebaser l'immuable ensemble de modifications" si les modifications à déplacer sont "publiques". Soit les forcer à être brouillon (avec des phases hg), soit passer --keepà la commande rebase, qui copiera au lieu de déplacer les modifications.
Jason R. Coombs du

A l' étape 4: abort: can't rebase immutable changeset 11b1e2b7dc4f. Notez que j'ai greffé des changesets d'une autre branche dans celle-ci. En plus de cela, il est divisé et fusionné gratuitement.
Mark Jeronimus

@Mark, jetez un œil à la note 3 ci-dessus.
alexis

6
Au lieu de valider un ensemble de modifications sur la nouvelle branche, puis de le rebaser par-dessus, vous pouvez l'omettre et l'utiliser .pour votre --destvaleur et le rebase prendra automatiquement le nouveau nom de la branche.
weberc2

16

Si vous avez des ensembles de modifications, vous devrez utiliser l' extension convert avec une branche pour la renommer. Tout le monde devra alors cloner le nouveau référentiel ou retirer l'ancienne branche.


1
Ceci est une solution intéressante, pouvez-vous élaborer un peu plus?
DrM

15

Créez une nouvelle branche appelée "mise en scène" et oubliez l'autre ...


+1 c'est ce que je ferais. Les anciens changesets auront toujours l'ancien nom de branche, mais les nouveaux auront le nouveau nom de branche.
barjak

6

Cela modifie l'historique et n'est destiné qu'aux utilisateurs avancés de Mercurial. Ne faites pas cela si vous ne savez pas ce que cela signifie.

Si le stigeage est local uniquement, vous pouvez le remplacer par un staging avec une combinaison de greffe et de bande . Commencez par mettre à jour l'ensemble de modifications de l'ancêtre où la stigmatisation avait divergé. Créez la branche intermédiaire et greffez chaque validation de la stigmatisation à la mise en scène. La mise en scène devrait maintenant être une copie de la stigmatisation. Enfin, détruisez les stigmates en supprimant son premier commit.

hg update {SHA-1 of the ancestor changeset}
hg branch staging
hg graft {first changeset in stiging} ... {stiging head-1} {stiging head}
hg strip {first changeset in stiging}
hg push --new-branch

1
Pour l'étape 3, vous pouvez utiliserhg graft {first changeset in stiging}..{stiging head}
KCD
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.