Avec Mercurial, comment puis-je «compresser» une série de changesets en un seul avant de pousser?

Disons que j'ai un référentiel Mercurial local et distant. Maintenant, je commence à travailler sur une fonctionnalité. Je travaille dessus, et quand je pense que c'est fait, je valide le changeset. En le testant un peu plus, je trouve que je pourrais encore améliorer 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é, donc je le corrige et je le valide aussi.

J'ai maintenant 3 changesets que j'aimerais vraiment pousser vers le référentiel distant comme un changeset avec le message "Implementing feature X", par exemple.

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

Qu'en est-il de l' extension de réduction ?

L' extension histedit est exactement ce que vous recherchez.

hg histedit -o

ou

hg histedit --outgoing

affichera une liste des changesets sortants. À partir de la liste, vous pouvez

• Pliez au moins 2 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 ensembles de modifications comme vous le souhaitez.

histedit vous demandera le nouveau message de validation des ensembles de modifications pliés qui par défaut les deux messages avec "\ n *** \ n" les séparant.

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

Vous pouvez également utiliser l'extension de réduction pour simplement faire un pliage, mais elle ne fournit pas une interface utilisateur aussi agréable et ne permet pas 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.

Oui, vous pouvez le faire avec des correctifs: supposons que votre travail se trouve dans les ensembles de modifications 100 à 110 inclus

1. Créez un patch:

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

2. Mettre à jour à 99:

   % hg update 99

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

   % hg import --no-commit mypatch

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

   % hg commit

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 diffèrent pour raison avant de supprimer les anciennes:

   % hg strip 100

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

Si vous utilisez TortoiseHg, utilisez peut simplement sélectionner deux révisions (utilisez CTRL pour sélectionner les non-suivantes), faites un clic droit et sélectionnez "Compresser l'historique" .

Après cela, vous obtiendrez une nouvelle liste de modifications dans la nouvelle tête à partir du premier changement que vous avez sélectionné auparavant, 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 pour cela. Encore une fois, dans TortoiseHg: faites un clic droit sur la première liste de modifications qui doit être supprimée avec tous ses descendants, "Modifier l'historique -> Supprimer" .

Ma méthode préférée d'utilisation de mq pour ce pliage est d'utiliser TortoiseHg comme décrit ici . Cependant, cela peut facilement être fait à partir de la ligne de commande comme ceci:

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 peut y avoir une meilleure façon de faire l'étape qfold, mais je ne suis pas au courant, car j'utilise habituellement 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 - en plus vous pouvez faire toutes sortes d'autres choses avec mq qui peuvent être très pratiques!

hg collapseet hg histeditsont les meilleurs moyens. Ou, plutôt, ce serait la meilleure façon, s'ils fonctionnaient de manière fiable ... Je suis arrivé histedità planter avec un vidage de pile en trois minutes. Collapsen'est pas tellement mieux.

J'ai pensé que je pourrais 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 hg rebaselimitations - en gros, cela n'aime pas le rebasage vers un ancêtre sur la même branche, nommée ou par défaut, bien qu'il le permette en cas de rebasage entre des branches (nommées).

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

Certaines personnes ont parlé de créer deux arborescences clones et de copier des fichiers entre elles. Ou patcher entre eux. Au lieu de cela, il est plus facile de déplacer les .hgrépertoires.

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

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

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

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

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

Pourquoi ne pas simplement hg strip --keepcommander?

Ensuite, vous pouvez valider toutes les modifications en un seul commit.

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 ensemble, l' extension de réduction fera l'affaire.

Supposons que vous ayez deux validations THISet non publiées THATdans Mercurial et que vous souhaitiez qu'elles se joignent en une seule validation au THISpoint ::

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

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

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

Mettre à jour pour LASTcommettre:

$ hg up

et import commits jusqu'à THISdans MQ ::

$ hg qimport $THIS::.

Désappliquez tous les correctifs et appliquez seulement en premier THIS:

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

Rejoignez THAT:

$ hg qfold $THATNAME

REMARQUE Pour trouver le nom, THATNAMEutilisez:

$ 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 rejoint deux commits dans Mercurial .

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