Pour Git 2.6+ (sortie le 28 Septembre 2015)

La seule git config qui serait d'intérêt est:

rebase.autoStash

lorsqu'il est réglé sur true, créer automatiquement une réserve temporaire avant le début de l'opération, et l'appliquer après la fin de l'opération.

Cela signifie que vous pouvez exécuter rebase sur un worktree sale.

cependant, utiliser avec soin: l'application de stash finale après un rebase réussi pourrait entraîner des conflits non-triviaux. Par défaut à false.

combinez cela avec:

pull.rebase

quand true, rebase les branches sur la branche récupérée, au lieu de fusionner la branche par défaut à partir de la télécommande par défaut quand "git pull" est lancé.

git config pull.rebase true
git config rebase.autoStash true

ce serait suffisant pour un simple git pull de travailler même dans un arbre sale.

Pas besoin d'alias dans ce cas.

---

Voir commettre 53c76dc (04 Juillet 2015) par Kevin Daudt ( Ikke ) .

^{(fusionné par Junio CA Hamano -- gitster -- dans commit e69b408 , 17 Aug 2015)}

pull : autoriser l'arbre sale quand rebase.autostash activé

rebase a appris à cacher les changements quand il rencontre un arbre sale, mais git pull --rebase ne l'est pas.

vérifier seulement si l'arbre qui travaille est sale quand rebase.autostash n'est pas permettre.

---

Note: Si vous voulez tirer sans autostash (même si rebase.autoStash true est fixé), vous avez depuis git 2.9 (juin 2016):

 pull --rebase --no-autostash

Voir commettre 450dd1d , commettre 1662297 , commettre 44a59ff , commettre 5c82bcd , commettre 6ddc97c , commettre eff960b , commettre efa195d (02 Avril 2016), et commettre f66398e , commit c48d73b (21 Mars 2016) by Mehul Jain ( mehul2029 ) .

^{(Regroupées par Junio C Hamano -- gitster -- dans commettre 7c137bb , 13 Avril 2016)}

Commettre f66398e comprend notamment:

pull --rebase : ajouter --[no-]autostash

si la variable de configuration rebase.autoStash est définie, il n'y a aucun moyen de outrepassez-le pour git pull --rebase " de la ligne de commande.

Enseigner " git pull --rebase " --[no-]autostash option de ligne de commande qui remplace la valeur actuelle de rebase.autoStash , si définie. Comme " git rebase " comprend l'option --[no-]autostash , c'est juste une question de passage l'option sous-jacente " git rebase , "quand" git pull --rebase " est appelé.

---

Avertissement: avant de Git 2.14 (T3 2017), " git pull --rebase --autostash " n'a pas d'auto-cachette quand l'histoire locale pour avancer rapidement vers l'amont.

Voir commettre f15e7cf (01 Juin 2017) par Tyler Brazier ( tylerbrazier ) .

^{(fusionné par Junio C. Hamano -- gitster -- dans commit 35898ea , 05 juin 2017)}

pull : ff --rebase --autostash œuvres dans de sales repo

quand git pull --rebase --autostash dans un dépôt sale en avant toute, rien n'était en train d'être autoclassé et la traction a échoué.

Cela était dû à un raccourci pour éviter de courir rebase quand nous pouvons avancer rapidement, mais autostash est ignoré sur ce chemin.

---

mise à Jour: Mariusz Pawelski demande dans les commentaires une question intéressante:

donc tout le monde écrit sur autostash quand vous faites rebase (ou pull --rebase ).

mais personne ne prend au sujet de l'autostashing quand vous faites traction normale avec fusionne .

Donc il n'y a pas de commutateur automatique pour ça? Ou je suis manque quelque chose? Je préfère faire git pull --rebase mais OP a demandé à propos de standard "git pull

réponse:

the original thread discussion de cette caractéristique autostash, il a été mis en œuvre à l'origine à la fois pour git pull (Fusion) et git pull --rebase .

mais... Junio C. Hamano (git maintainer) a noté que:

si le pull-merge était quelque chose qui provoquerait la "gêne"" qui a déclenché ce sujet, par définition, la modification locale des chevauchements avec la fusion, et cette "stash pop" va toucher les chemins la fusion a touché et il n'est probablement pas le résultat "tombé", mais laisser d'autres conflits doivent être résolus.

je soupçonne que la configuration pull.autostash n'est pas une bonne addition parce qu'elle encourage une mauvaise, douleur-inducteur workflow.

Dans les cas simples, cela peut ne pas faire de mal, mais lorsque les changements locaux sont complexes, il serait activement mal de ne pas l'avoir, et la configuration prive l'incitation à choisir.

L'équation est quelque peu différente pour le "pull-rebase", "rebase" insiste pour que vous partiez d'un arbre de travail propre, donc " télécharger et alors arrête" la gêne semble plus grande. Je soupçonne que desserrer qui peut être une solution plus productive au problème réel.

donc, en ce qui concerne un classique pull-merge, il est préférable de:

encouragez l'utilisateur à réfléchir à la nature de la WIP qu'il a dans l'arbre de travail avant de lancer " git pull .

Est-ce une bête trop complexe qui peut interférer avec ce que les autres font, ou est-ce un changement insignifiant qu'il puisse le cacher et le ramener?

si la l'ancien, il sera beaucoup mieux de faire " checkout -b ", garder travailler jusqu'à ce que le changement local soit en quelque sorte dans une meilleure forme et "commit", avant de tirer dans la branche originale.

si ce dernier, il est mieux de faire:

• " git pull ",
• après avoir trouvé des conflits, Lancez
  • git stash ,
  • git merge FETCH_HEAD et
  • git stash pop