Hg : Comment faire un rebasage comme git ' rebase s

Question

Dans Git, je peux faire ceci:

1. Commencer à travailler sur une nouvelle fonctionnalité:
$ git co -b newfeature-123 # (un local de développement de la branche)
faire quelques commits (M, N, O)

maître A---B---C
\
newfeature-123 M---N---O

2. Tirez sur les nouveaux changements de l'amont maître:
$ git pull
(master mis à jour avec ff-commits)

maître A---B---C---D---E---F
\
newfeature-123 M---N---O

3. Rebase de master ainsi que ma nouvelle fonctionnalité 
peut être mis au point contre les derniers changements en amont:
(à partir de newfeature-123)
$ git rebase maître

maître 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 donne 2 exemples:
1. Je vais vous avouer que cela: (en remplacement de la révision à partir de l'exemple avec ceux de mon propre exemple)

hg-C F 
hg branche -f newfeature-123 
hg greffe -a-b newfeature-123 

n'est pas trop mal, sauf qu'il laisse derrière lui le pré-rebase M-Pas comme un dissociées de la tête et crée 3 nouveaux commits M',N',O' qui les représentent embranchement à partir de la mise à jour de la ligne principale.

Fondamentalement, le problème est que je me retrouve avec ceci:

maître 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, indésirables s'engage à ce que devrait être abandonnée.

1. L'autre option à partir du même lien

hg qimport -r M:O
hg qpop -un
hg jusqu'F
hg branche newfeature-123
hg qpush -un
hg qdel -r qbase:qtip

et cela a pour conséquence le graphique souhaité:

maître A---B---C---D---E---F
\
newfeature-123 M---N---O

mais ces commandes (tous les 6 d'entre eux!) l'air beaucoup plus compliqué que

$ git rebase maître

Je veux savoir si c'est le seul équivalent en Hg ou si il y a une autre manière qui est simple comme Git.

Answer 1

VonC a la réponse que vous cherchez, le Rebase Extension. Il est, cependant, la peine de dépenser une seconde ou deux de réflexion sur le pourquoi ni mq ni rebase sont activés par défaut dans mercurial: comme mercurial est tout au sujet indélébile révisions. Quand je travaille de la manière que vous décrivez, ce qui est presque tous les jours, voici le modèle que j'ai:

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 vraiment tout ce qui est nécessaire. Je me retrouve avec un newfeature-123 clone, je peux facilement pousser vers le réseau principal quand je suis heureux avec elle. Plus important encore, cependant, j'ai jamais changé l'histoire. Quelqu'un peut regarder mon csets et voir ce qu'ils ont été à l'origine codage et de la façon dont j'ai réagi à des changements dans la canalisation principale tout au long de mon travail. Tout le monde ne pense qu'a de la valeur, mais je suis un croyant ferme que c'est le travail de contrôle de source pour nous montrer pas ce que nous voulions était arrivé, mais ce qui s'est réellement passé, chaque cul-de-sac et de tous les refactoriser doit laisser une trace indélébile, et la relocalisation et d'autres de l'histoire des techniques de montage cacher.

Maintenant aller chercher VonC de réponse alors que j'ai mis ma boîte à savon loin. :)

Answer 2

Quel est le problème avec le Rebase Extension? (mis en œuvre dans le cadre de la SummerOfCode 2008)

Dans ces cas, il peut être utile de "détacher" les changements locaux, de synchroniser le référentiel général puis ajouter le privé changements sur le dessus de la nouvelle télécommande changements. Cette opération est appelée rebase.

Arriver à partir de:

pour:

Answer 3

En supposant que vous disposez d’une installation moderne de Hg, vous pouvez simplement ajouter :

à ~ / .hgrc.

Vous pouvez utiliser les commandes , , ou `` .

Answer 4

Je ne pense pas que les réponses ci-dessus parvenir à l'OP de l'objectif, qui est de maintenir sa tâche de direction, juste relocalisée à l'encontre d'un moment plus tard, sur le parent de la branche.

Disons que je commence avec ce graphique (généré à l'aide de la graphlog extension. 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 le feature3 branche et souhaitez rebase hors de l'againagainagain s'engager, je comprends que je courrais hg rebase -d default. Cela a le résultat suivant:

@  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 l'engage sur le feature3 branche ont été relocalisée sur againagainagain, le feature3 branche a été supprimé. Mes commits ont été déplacés à la branche par défaut, ce qui était ce que j'essayais d'éviter en premier lieu.

Dans Git, le résultat devrait ressembler à ceci:

@  9a4c0eb66429 Feature 3 commit 2 tip
|
o  98bdde5d2185 Feature 3 branch commit 1 **feature3**
|
o  af630ccb4a80 default againagainagain
|
o  e9f850ac41da foo

Notez que le feature3 branche existe encore, les deux commits sont toujours sur le feature3 branche, et n'est pas visible par défaut. Sans la préservation de la tâche de direction, je ne vois pas comment ce est fonctionnellement différentes à partir d'une fusion.

Mise à JOUR: j'ai découvert l' --keepbranches drapeau pris en charge par hg rebase, et je suis heureux de signaler tout est okey-dokey. À l'aide de hg rebase -d default --keepbranches, j'ai exactement reproduire le Git comportement je désirais. Un couple de alias plus tard et je suis rebasage comme personne.