Supprimer tous les ensembles de modifications locaux et revenir à l'arborescence

95

J'utilise Mercurial et je suis dans un terrible désordre localement, avec trois têtes. Je ne peux pas pousser, et je veux juste supprimer tous mes changements et commits locaux et recommencer avec un code totalement propre et un historique propre.

En d'autres termes, je veux me retrouver avec (a) exactement le même code localement que celui qui existe dans la pointe de la branche distante et (b) aucun historique des commits locaux.

Je sais hg update -Cécrase tous les changements locaux. Mais comment supprimer des commits locaux?

Pour être clair, je n'ai aucun intérêt à préserver le travail que j'ai effectué localement. Je veux juste le moyen le plus simple de revenir à une caisse locale totalement propre.

— Richard
source

Possible en double de Y at - il de moyen de supprimer commits locaux Mercurial?

— UuDdLrLrSs

129

Lorsque le moyen le plus simple (un nouveau hg clone) n'est pas pratique, j'utilise hg strip:

% hg outgoing -l 1
% hg strip $rev # replace $rev with the revision number from outgoing

Répétez jusqu'à ce que hg outgoingreste calme. Notez que hg strip $revoblitère $revet tous ses descendants.

Notez que vous devrez peut-être d' abord activer stripdans vos paramètres Mercurial .

PS: une approche encore plus intelligente consiste à utiliser le langage revset et à faire:

% hg strip 'roots(outgoing())'

— juste quelqu'un
source

1

Je vous remercie! Je me suis retrouvé dans une situation que cela a parfaitement résolu, sans aucun problème.

— eswald

1

Cela m'a sauvé des gros correctifs ci-dessus, très simple, merci!

— David C

3

Si quelqu'un a des problèmes hg strip 'roots(outgoing())'pour se rendre au travail parce qu'il ne reconnaît pas 'roots(outgoing())'. J'ai pu le faire fonctionner hg strip "roots(outgoing())".

— jsea

@SombreErmine dedans cmd.exe, oui.

— juste quelqu'un

21

Vous souhaiterez créer un clone local dans lequel vous ne conserverez que les ensembles de modifications qui sont également présents dans le référentiel distant. Utilisez TortoiseHg , hg logou similaire à la figure qui de vos révisions est que la révision lastest vous ne l' avez pas faire (celui avant le désordre a commencé). L'utilisation hg outgoingpeut vous aider ici - elle répertorie tous les ensembles de modifications que vous avez effectués - choisissez un numéro de révision antérieur à l'un d'entre eux.

Si la révision cible est appelée goodet votre clone est appelé foo, procédez comme suit:

hg clone -r good foo foo-clean

Ce sera une opération locale rapide - il n'y a aucune raison de tout télécharger à nouveau . Le foo-cleanclone ne contiendra que des ensembles de modifications jusqu'à la révision good. Vous pouvez maintenant remplacer foo-clean/.hg/hgrcpar foo/.hg/hgrcafin de conserver les paramètres locaux de votre référentiel tels que le chemin push / pull par défaut.

Lorsque vous êtes satisfait de foo-cleantout ce dont vous avez besoin foo, supprimez fooet renommez simplement foo-cleanen foo. Faites a hg pullpour obtenir tous les nouveaux ensembles de modifications du référentiel distant dans votre clone et continuez comme d'habitude.

Si personne n'a poussé de nouveaux ensembles de modifications vers le référentiel distant, alors il est très simple de déterminer la révision que vous souhaitez utiliser comme goodci-dessus: hg id defaultvous indiquera l'ID de la pointe dans le référentiel distant.

— Martin Geisler
source

J'ai la même situation, mais j'ai aussi beaucoup de fichiers dans le répertoire repo mais sont dans le hgignore. Impossible d'installer la bande hg et je voudrais supprimer les commits locaux sans remplacer tout le clone. Des idées? - Ah! Si je n'ai ajouté aucun fichier, je devrais pouvoir simplement copier l'autre clone dans mon ancien répertoire !?

— Peteter

Soyez prudent avec cette méthode si vous avez plusieurs branches, cependant. Le clonage jusqu'à une révision spécifiée obtient uniquement les ensembles de modifications sur la branche de la révision spécifiée. Vous devrez peut-être alors hg pull -rpour la dernière «bonne» révision de chaque branche supplémentaire.

— Yitz

9

D'accord. Supprimez donc simplement tous les éléments locaux, hg initle nouveau référentiel local et hg pullla dernière astuce que vous avez. N'oubliez pas hg updateaprès cela.

— alemjerus
source

Merci. Lorsque vous dites «supprimer tous les éléments locaux», voulez-vous dire supprimer tout le référentiel ou simplement mes modifications? Que fait hg init (a Google mais ne peut pas voir une explication simple) et dois-je utiliser des indicateurs avec? Va-t-il supprimer des éléments tels que mes préférences Mercurial .hgrc?

— Richard

Mise à jour: si je supprime tout dans le répertoire racine du projet, puis tapez 'hg init', j'obtiens 'abort: repository. existe déjà!'. Dois-je configurer et travailler à partir d'un nouveau répertoire? Je préfère pas si possible ... il doit sûrement y avoir un moyen simple de tuer tout ce que j'ai fait localement?!

— Richard

Oui, supprimez tout, y compris tous les éléments du référentiel. Commencez à partir d'un nouveau dossier propre. Vos préférences, vous pouvez enregistrer dans le fichier de sauvegarde, puis les restaurer dans le nouveau référentiel que vous créez avec hg init reponame. Détails sur init et trucs: hgbook.red-bean.com/read/mercurial-in-daily-use.html

— alemjerus

6

alemjerus: hg init+ hg pull= hg cloneLa différence est que cela hg clonefait un joli .hg/hgrcfichier pour vous et qui hg cloneutilisera des liens physiques pour économiser de l'espace lors du clonage sur le même système de fichiers.

— Martin Geisler

Richard: La sortie de hg help initest ici: selenic.com/mercurial/hg.1.html#init Mais c'est peut-être trop laconique? Veuillez envoyer un e-mail à notre liste de diffusion si vous avez besoin de plus d'aide! Voir: mercurial.selenic.com/wiki/MailingLists

— Martin Geisler

5

Vous pouvez utiliser

révision de bande hg

pour tuer toute révision et son sous-arbre dans votre référentiel local.

https://www.mercurial-scm.org/wiki/Strip

Mais n'essayez pas de l'utiliser pour tout ce qui a déjà été poussé.

— Averasko
source

Vous pouvez l'utiliser sur une révision publique, mais si vous tirez à nouveau, il réapparaîtra. (hg strip ne fonctionne qu'avec le référentiel local.)

— Mike Rosoft

2

Supprimez simplement tout ce que vous avez sur votre système local et re-clonez le dépôt distant.

— JO.
source

2

hg strip `hg out --template" {rev} {auteur} \ n "| grep YOUR_AUTHOR_NAME | couper -d "" -f 1`

fait l'affaire pour moi.

Il supprime toutes les révisions qui ne sont pas transmises au référentiel par défaut qui sont créées avec votre nom d'auteur.

Vous pouvez également utiliser ce style pour qu'il ne vérifie pas avec le référentiel par défaut mais avec un autre référentiel

hg strip `hg out OTHER_REPO_ALIAS --template" {rev} {author} \ n "| grep YOUR_AUTHOR_NAME | couper -d "" -f 1`

— Sébastien
source

0

Si vous utilisez TortoiseHg, un moyen simple de sortir d'un (petit) désordre est de commencer par mettre à jour la dernière révision, puis de sélectionner vos ensembles de modifications et de lancer "fusionner avec local". Lorsque la boîte de dialogue de fusion apparaît, cliquez simplement sur la petite icône «+» pour afficher des options supplémentaires, dont l'une est «rejeter les ensembles de modifications de la (autre) révision de la cible de fusion». Cela signifie que vos ensembles de modifications seront toujours dans le dépôt et seront poussés, mais n'auront aucun effet, car ils seront supprimés lors de la fusion. Si vous avez beaucoup d'ensembles de modifications couvrant plusieurs têtes, vous ne voudrez peut-être pas polluer le dépôt de cette manière, mais c'est une solution simple et il vaut la peine de considérer si les ensembles de modifications que vous supprimez contiennent des données que vous voudrez peut-être référencer plus tard.

— MrFlamey
source