Hg: Comment faire un rebase comme le rebase de git
en Git je peux le faire:
1. Start working on new feature:
$ git co -b newfeature-123 # (a local feature development branch)
do a few commits (M, N, O)
master A---B---C
newfeature-123 M---N---O
2. Pull new changes from upstream master:
$ git pull
(master updated with ff-commits)
master A---B---C---D---E---F
newfeature-123 M---N---O
3. Rebase off master so that my new feature
can be developed against the latest upstream changes:
(from newfeature-123)
$ git rebase master
master A---B---C---D---E---F
newfeature-123 M---N---O
je veux savoir comment faire la même chose dans Mercurial, et j'ai écumé le web pour une réponse, mais le meilleur que j'ai pu trouver était: git rebase - peut hg faire
ce lien fournit 2 Exemples:
1. J'admets que ceci: (remplacer les révisions de l'exemple par celles de mon propre exemple)
hg up -C F hg branch -f newfeature-123 hg transplant -a -b newfeature-123
n'est pas trop mauvais, sauf qu'il laisse derrière le pré-rebasé M-N-O comme une tête non fusionnée et crée 3 nouvelles propagations M',N',O' qui les représentent en branchant hors de la ligne principale mise à jour.
Fondamentalement, le problème est que je me retrouve avec ceci:
master A---B---C---D---E---F
newfeature-123 M'---N'---O'
newfeature-123 M---N---O
ce n'est pas bon parce qu'il laisse derrière local, commits indésirables qui devraient être abandonnés.
- l'autre option de la même lien est
hg qimport -r M:O hg qpop -a hg up F hg branch newfeature-123 hg qpush -a hg qdel -r qbase:qtip
et il en résulte le graphique désiré:
master A---B---C---D---E---F
newfeature-123 M---N---O
mais ces commandements (tous les 6!) semblent tellement plus compliquées que
$ git rebase master
je veux savoir si C'est le seul équivalent en Hg ou s'il existe un autre moyen simple comme le Git.
5 réponses
VonC a la réponse que vous recherchez , L'Extension Rebase. Il vaut cependant la peine de réfléchir une seconde ou deux à la raison pour laquelle ni mq ni rebase ne sont activés par défaut dans mercurial: parce que mercurial est tout au sujet des changesets indélébiles. Quand je travaille de la manière que vous décrivez, ce qui est presque quotidien, voici le modèle que je prends:
1. Start working on a new feature:
$ hg clone mainline-repo newfeature-123
do a few commits (M, N, O)
master A---B---C
\
newfeature-123 M---N---O
2. Pull new changes from upstream mainline:
$ hg pull
master A---B---C---D---E---F
\
newfeature-123 M---N---O
3. merge master into my clone so that my new feature
can be developed against the latest upstream changes:
(from newfeature-123)
$ hg merge F
master A---B---C---D---E---F
\ \
newfeature-123 M---N---O---P
et c'est tout ce qui est nécessaire. Je me retrouve avec un nouveau clone-123 I peut facilement revenir à la ligne principale quand je suis heureux avec elle. Plus important encore, cependant, je jamais changé l'histoire . Quelqu'un peut regarder mon csets et voir ce contre quoi ils ont été initialement codés et comment j'ai réagi aux changements dans la ligne principale tout au long de mon travail. Tout le monde ne pense pas que cela a de la valeur, mais je crois fermement que c'est le travail du contrôle à la source de nous montrer non pas ce que nous aurions voulu qu'il se soit passé, mais ce qui s'est réellement passé -- chaque point mort et chaque réflecteur devrait laisser une trace indélébile, et le rebasage et d'autres techniques d'édition d'histoire cachent cela.
maintenant, va chercher la réponse de VonC pendant que je range ma boîte à savon. :)
vous pourriez être à la recherche de Rebase Extension . (mis en œuvre dans le cadre du SummerOfCode 2008 )
dans ces cas, il peut être utile de" détacher " les modifications locales, de synchroniser le dépôt avec le mainstream et d'ajouter les modifications privées aux nouvelles modifications à distance. Cette opération s'appelle rebase.
Obtenir :
à:
en supposant que vous avez une installation moderne de Hg, vous pouvez simplement ajouter:
[extensions]
rebase =
to ~/.hgrc.
, Alors vous pouvez utiliser les commandes hg rebase , hg pull --rebase , ou hg help rebase .
Je ne pense pas que les réponses ci-dessus atteignent le but de L'OP, qui était de maintenir sa branche de tâche, juste rebasé contre un point plus tard sur la branche mère.
disons que je commence avec ce graphique (généré en utilisant l'extension graphlog. Sérieux geek amour pour graphlog).
@ 9a4c0eb66429 Feature 3 commit 2 tip feature3
|
| o af630ccb4a80 default againagainagain
| |
o | 98bdde5d2185 Feature 3 branch commit 1 feature3
|/
o e9f850ac41da foo
si je suis sur la branche feature3 et que je veux la rebaser hors de la propagation à nouveau, je comprends que je courrais hg rebase -d default . Ce sont les suivantes résultat:
@ 89dada24591e Feature 3 commit 2 tip
|
o 77dcce88786d Feature 3 branch commit 1
|
o af630ccb4a80 default againagainagain
|
o e9f850ac41da foo
Mission accomplie? Je ne le pense pas. Le problème est que lorsque les commits sur la branche feature3 ont été rebasés sur againagain, la branche feature3 a été supprimée . Mes commits ont été déplacés vers la branche par défaut, ce que j'essayais d'éviter en premier lieu.
en Git, le résultat ressemblerait à ceci:
@ 9a4c0eb66429 Feature 3 commit 2 tip
|
o 98bdde5d2185 Feature 3 branch commit 1 **feature3**
|
o af630ccb4a80 default againagainagain
|
o e9f850ac41da foo
noter que la caractéristique 3 Branche existe toujours, les deux commits sont toujours sur la branche feature3, et ne sont pas visibles par défaut. Sans préserver la branche des tâches, Je ne vois pas en quoi cela diffère fonctionnellement d'une fusion.
UPDATE : j'ai découvert le drapeau --keepbranches supporté par HG rebase, et je suis heureux de signaler que tout est okey-dokey. En utilisant hg rebase -d default --keepbranches , j'imite exactement le comportement que je désirais. Quelques alias plus tard et je me rebase comme si de rien n'était.
depuis que certaines personnes ont sonné en disant qu'ils pensent qu'il est bon de garder chaque itération de tout, je vais souligner que pour les grands projets open-source, accepter des changements pleins de fusions et d'itération de développement ferait pour une histoire de révision de ligne principale brouillée, et rendre l'histoire de révision moins utile pour voir comment la version actuelle est arrivée là.
cela fonctionne bien quand les changements soumis sont examinés par des gens qui ne les ont pas écrits, avant qu'ils ne soient accepté, donc les changements qui vont dans la ligne principale sont généralement débogués et fonctionnent. Puis quand vous revenez à l'origine d'une ligne, vous voyez tous les changements qui vont avec elle, pas un point au milieu du développement du changement dont elle fait partie.
le processus consiste à mettre hg à jour vers la pointe amont, puis à obtenir toutes vos modifications non engagées dans le répertoire de travail. Mettez de côté tout ce qui ne fait pas partie de ce que vous voulez soumettre, puis cassez le reste en autant de commits séparés sont appropriés, avec de beaux messages de commit.
je suppose que vous copiez / collez et puis éditez commit des messages d'itérations précédentes d'un patchset que vous révisez. Ou peut-être pourriez-vous greffer vos anciennes commits ("cherry-pick" en langage git), puis les modifier une par une, pour obtenir vos anciens messages de commit comme point de départ pour la modification.