Mercurial dit "abandon: modifications non validées en suspens", je ne veux pas m'engager

Question

Scénario: Local repo, avant que je ne quitte le bureau

$ hg status

M important/update1
M another/important/update2
M work/in/progress

Je veux commit et push important/update1 et important/update2, parce que je veux tirer de ces fichiers à mon local repo quand je rentre à la maison. Je ne suis pas prêt à s'engager de travail/dans le/le progrès. En fait, il n'a même pas analyser correctement. Ce fichier est ouvert dans mon IDE et j'ai juste envie de le laisser comme il est.

Maintenant, je fais: (à la hâte, le tram s'arrête à trois minutes)

$ hg commit important/update1 another/important/update2
$ hg push

pushing to https://**censored**
searching for changes
abort: push creates new remote heads on branch 'default'!
(did you forget to merge? use push -f to force)

Ok. Un collègue a poussé quelque chose... (tram feuilles en deux minutes...)

$ hg pull (really important update!)
$ hg update

abort: outstanding uncommitted changes

De la merde. J'ai besoin de vos collègues de mise à jour mais je ne vais pas commettre de travail/dans le/le progrès, beaucoup moins de pousser! Et j'ai raté mon tram...

Comment réagissez-vous face à cela?

Answer 1

Si vous ne souhaitez pas utiliser shelve, vous pouvez le faire avec seulement 3 commandes:

 hg diff > mylocalchanges.txt

hg revert -a

# Do your merge here, once you are done, import back your local mods

hg import --no-commit mylocalchanges.txt
 

Answer 2

Utilisez l' extension du grenier pour ranger / enregistrer temporairement les travaux en cours.

Answer 3

Un flux de travail pour les personnes qui développent plusieurs fonctionnalités et des corrections de bugs dans le même temps:

Une possibilité serait de cloner autant de dépôts que des fonctionnalités de vous développer. Mais cela peut être coûteux en espace disque, temps, et aussi à confusion. Une autre possibilité est de travailler sur différents sujets sur le même référentiel local (appelons ça de la Main), mais juste utiliser un second sélective de commettre une ou plusieurs des caractéristiques recherchées pour le dépôt central.

C'est très bien expliqué et détaillé dans cet article:

https://blogs.oracle.com/tor/entry/mercurial_tip_checking_in_regularly

Si jamais vous rencontrez des messages d'erreur suivants:

• "abort: push crée de nouveau à distance têtes!" (potentiel de plusieurs têtes)
• "abort: traverse les branches (utilisation "hg merge" ou "hg update-C')" (working dir dans une autre branche que l'tiré des changements), ou
• "abort: en circulation les modifications non validées" (impossible de fusionner en raison de modifications locales)

puis l'article ci-dessus explique pourquoi tout ce qui se passe, et propose un flux de travail pour éviter ces problèmes. Remarque: il est également possible d'utiliser mqueues patch mécanisme de pousser vos modifications (voir commentaire#1 de l'article).

Espère que ça vous aidera.

Answer 4

J'utilise généralement l' extension de l'étagère TortoiseHg , que vous pouvez également activer pour utiliser sur votre ligne de commande:

 [extensions]
tortoisehg.util.hgshelve =
 

Vous pouvez maintenant utiliser les commandes:

 $ hg shelve
 

Si vous savez que la mise à jour n'interfère pas avec notre travail, vous pouvez également forcer l'extraction / mise à jour ( hg pull -f ).

Answer 5

Si vous êtes à la poussant simplement pour exposer code pour le réseau, de sorte que vous pouvez retirer et continuer à travailler à la maison, je ne sais pas que votre collègue devrait être de pousser à la même repo. Vous pourriez envisager d'utiliser un développeur référentiel: une pension pour votre utilisation personnelle, soit par les autorisations, ou tout simplement par respect/politesse).

Certains programmes (tels que les FogCreek du Four SW) offrent cette fonctionnalité, mais même si vous venez de magasin de repos sur un réseau/lecteur partagé, vous devriez être en mesure de créer un personnel pensions de là.

Si ce n'est pas le cas (c'est à dire: vous n'avez pas les autorisations du serveur), vous pouvez également envisager d'utiliser un nom de branche. Dans ce cas, il vous suffit de s'engager à votre branche nommée et pousser la branche vers le serveur. Sans doute votre collègue pourrait laisser vos branches nommées seul et il n'y aurait rien de nouveau à tirer et fusionner. En termes de branche "fouillis", oui ils sont présents pendant toute la durée de l'opération, mais la fermeture de la branche nommée juste avant la fusion, vous les retirez de votre vue et de résoudre certains problèmes.

> hg update <branch name>
> hg commit --close-branch -m 'closing branch <branch name>'

À la fin de la journée, je ne considère pas la direction de l'encombrement d'être une préoccupation majeure, à moins que vous (a) ont un géant de l'équipe ou (b) ne sont pas la fermeture de vos branches.