Avec Mercurial, comment puis-je compresser & # 8221; une série de changesets en un avant de pousser?

Question

Disons que j'ai un référentiel Mercurial local et distant. Maintenant, je commence à travailler sur une fonctionnalité. J'y travaille, et quand je pense que c'est fait, je valide la modification. En testant un peu plus, je trouve que je pourrais améliorer encore cette fonctionnalité en modifiant quelque chose dans le code. Je fais le changement et je m'engage. 20 minutes plus tard, je trouve qu'il y a un bogue dans cette nouvelle fonctionnalité. Je le répare donc et le commets aussi.

J'ai maintenant 3 changesets que j'aimerais vraiment transférer dans le référentiel distant en tant qu'un changeset avec le message "Implémentation de la fonctionnalité X", par exemple.

Comment puis-je faire cela sans trop de soucis? Je pense que je pourrais le faire avec des correctifs, mais cela me semble beaucoup de travail.

Answer 1

Qu'en est-il de la Réduire l'extension ?

Answer 2

L'extension histedit est exactement ce que vous recherchez. .

hg histedit -o

ou

hg histedit --outgoing

affichera une liste des changesets sortants. Dans la liste, vous pouvez

• Pliez deux ou plusieurs ensembles de modifications en créant un seul ensemble de modifications
• Supprimer les ensembles de modifications en les supprimant de l'historique
• Réorganisez les changesets comme bon vous semble.

histedit vous invitera à saisir le nouveau message de validation des jeux de modifications repliés, dont les valeurs par défaut sont les deux messages avec "& n; \ n *** \ n". en les séparant.

Vous pouvez également obtenir des résultats similaires avec l’extension mq, mais c’est beaucoup plus difficile.

Vous pouvez également utiliser l'extension collapse uniquement pour le pliage, mais cela ne fournit pas une interface utilisateur aussi agréable ni un moyen de modifier le message de validation résultant. La modification du message de validation résultant permet également de nettoyer le message final, ce que je finis toujours par utiliser.

Answer 3

Oui, vous pouvez le faire avec des correctifs: Supposons que votre travail se situe dans les changesets 100 à 110 inclus,

1. Créez un patch:

   % hg export -o mypatch 100: 110 --git

2. Mettre à jour à 99:

   % hg mise à jour 99

3. Appliquez le correctif avec --no-commit (sinon, vous récupérerez tous vos ensembles de modifications):

   % hg import --no-commit mypatch

4. Valider toutes les modifications en même temps:

   commit% hg

5. Vous avez maintenant deux têtes (110 et 111) qui devraient être équivalentes en termes de fichiers qu'elles produisent dans votre répertoire de travail - peut-être les modifier pour des raisons de santé avant de supprimer les anciennes:

   % hg strip 100

OK, maintenant que j'ai tout expliqué, cela semble long, mais l'ayant fait moi-même plusieurs fois, je ne trouve pas que ce soit une corvée trop lourde ...

Answer 4

Si vous utilisez TortoiseHg, vous pouvez simplement sélectionner deux révisions (utilisez la combinaison de touches CTRL pour sélectionner celles qui ne le sont pas), faites un clic droit et sélectionnez "Compresser l'historique" .

Ensuite, vous obtiendrez une nouvelle liste de modifications dans new head à partir de la première modification que vous avez précédemment sélectionnée. Elle contiendra toutes les listes de modifications descendantes entre celles que vous avez sélectionnées.

Vous pouvez simplement supprimer les anciennes listes de modifications si vous n'en avez plus besoin: utilisez les extensions MQ . Encore une fois, dans TortoiseHg: faites un clic droit sur la première liste de modifications à supprimer avec tous ses descendants, " Modifier l'historique - > Bande ".

Answer 5

Ma méthode préférée d’utilisation de mq pour ce pliage est d’utiliser TortoiseHg comme décrit ici . Cependant, vous pouvez facilement le faire depuis la ligne de commande, comme suit:

hg qimport -r <first>:<last> 
    -- where <first> and <last> are the first and last changesets 
    -- in the range of revisions you want to collapse

hg qpop <first>.diff
    -- remove all except for the first patch from the queue
    -- note: mq names patches <#>.diff when it imports them, so we're using that here

hg qfold <next>.diff
    -- where <next> is <first>+1, then <first>+2, until you've reached <last>

hg qfinish -a
    -- apply the folded changeset back into the repository

(Il y a peut-être une meilleure façon de faire l'étape qfold, mais je n'en ai pas conscience, j'utilise généralement TortoiseHg pour cette opération.)

Cela semble un peu compliqué au début, mais une fois que vous avez commencé à utiliser mq, c’est assez simple et naturel. De plus, vous pouvez faire toutes sortes d’autres choses avec mq qui peuvent être très pratiques!

Answer 6

hg collapse et hg histedit sont les meilleurs moyens. Ou, au contraire, seraient les meilleurs moyens, s’ils fonctionnaient de manière fiable ... J’ai demandé à histedit de planter avec un vidage de pile dans les trois minutes. Collapse n'est pas tellement mieux.

Je pensais pouvoir partager deux autres BKM:

1. hg rebase --collapse

   Cette extension est distribuée avec Mercurial. Je n'ai pas encore eu de problèmes avec ça. Vous devrez peut-être jouer à certains jeux pour contourner les limitations de hg rebase . En gros, il n'aime pas être rebasé vers un ancêtre de la même branche, nommé ou par défaut, bien qu'il le permette si rebaser entre branches (nommées).

2. Déplacez le référentiel ( foo / .hg ) dans le répertoire de travail ( bar ) et ses fichiers. Pas l'inverse.

Certaines personnes ont parlé de la création de deux arbres de clonage et de la copie de fichiers entre eux. Ou se patcher entre eux. Au lieu de cela, il est plus facile de déplacer les répertoires .hg .

hg clone project work
... lots of edits
... hg pull, merge, resolve
hg clone project, clean
mv work/.hg .hg.work
mv clean/.hg work/.hg
cd work
... if necessary, pull, nerge, reconcile - but that would only happen because of a race
hg push

Ceci fonctionne tant que les vrais référentiels, les arborescences .hg , sont indépendants du répertoire de travail et de ses fichiers.

S'ils ne sont pas indépendants ...

Answer 7

Je n'ai jamais utilisé Mercurial, mais cela ressemble beaucoup à ce dont Martin Fowler parlait il y a peu sur son blog:

http://martinfowler.com/bliki/MercurialSquashCommit.html

Answer 8

Pourquoi ne pas simplement utiliser la commande hg strip --keep ?

Ensuite, vous pouvez valider toutes les modifications en une seule validation.

Answer 9

HistEdit fera ce que vous voulez, mais c'est probablement exagéré. Si la seule chose dont vous avez besoin est de plier certains ensembles de modifications, Collapse Extension fera le travail.

Answer 10

Supposons que vous ayez deux THIS non publiés et QUE s’engage dans Mercurial et qu’ils aimeraient s’associer à un commit unique à THIS point ::

... --> THIS --> ... --> THAT --> ... --> LAST

Vérifiez que vos commits ne sont pas publiés ::

$ hg glog -r "draft() & ($THIS | $THAT)"

Mise à jour vers LAST commit ::

$ hg up

et importer commet jusqu'à THIS dans MQ ::

$ hg qimport $THIS::.

Désappliquez tous les correctifs et n'appliquez que le premier THIS ::

$ hg qpop -a
$ hg qpush
$ hg qapplied
... THIS ...

Rejoindre avec QUE ::

$ hg qfold $THATNAME

REMARQUE Pour rechercher le nom THATNAME , utilisez ::

.

$ hg qseries

Appliquez tous les correctifs et déplacez-les vers l'historique du référentiel ::

$ hg qpush -a
$ hg qfinish -a

Mon article de blog sur le sujet est Rejoindre deux commits dans Mercurial .

Answer 11

Oui, strip --keep fonctionne pour la question de l'auteur. Mais c'était légèrement différent des autres, par exemple, si vous avez une version de 1 à 30 mais que vous voulez seulement réduire la version 12-15. D'autres solutions fonctionnent, mais pas strip -keep .