Digo que tengo un repositorio de git cuyo árbol y / o índice de trabajo está "sucio" (es decir, tengo modificaciones locales que aún no se han confirmado o ocultado) y estoy tentado a hacer un "git pull" sin antes cometer o guardar . (Alternativamente, digamos que estoy presentando a un nuevo miembro del equipo a git yello están tentados a ejecutar "git pull" cuandos repo local está "sucio".) Me pregunto qué tan seguro es hacer un "git pull" en este caso. Si no es seguro, ¿qué es lo peor que puede pasar? ¿Importa si extraigo de una fuente confiable o no confiable?

Mi investigación hasta ahora sugiere una gama confusa de ideas sobre lo que supuse que sería una pregunta bastante sencilla.

Para empezar, la página de manual de git-stash hace que parezca que git pull es bastante seguro y abortará si estás en una situación en la que algo podría salir mal:

   Pulling into a dirty tree
       When you are in the middle of something, you learn that there are
       upstream changes that are possibly relevant to what you are doing.
       When your local changes do not conflict with the changes in the
       upstream, a simple git pull will let you move forward.

       However, there are cases in which your local changes do conflict
       with the upstream changes, and git pull refuses to overwrite your
       changes. In such a case, you can stash your changes away, perform a
       pull, and then unstash, like this...

Esto en realidad parece ser lo que sucede también, en mis pruebas simples hasta ahora.

También quizás implica que "git pull" es bastante seguro, el Extensiones de Git toolbar para Visual Studio tiene un destacado botón de extracción que no verifica la suciedad antes de desembocar en "git pull". (Si estuviera diseñando una barra de herramientas de Visual Studio, trataría de evitar que sea particularmente fácil dispararse en el pie).

La página de manual de git-pull no hace que mi "git pull" suene peligroso, aunque sugiere que no es una mejor práctica:

   If any of the remote changes overlap with local uncommitted changes,
   the merge will be automatically cancelled and the work tree untouched.
   It is generally best to get any local changes in working order before
   pulling or stash them away with git-stash(1).

Pero entonces también puedes encontrar consejos de que tirar a la suciedad es muy malo,p.ej:

Avoid git-pull!
git-pull should never get invoked if you have dirty files lying around or if your branch is ahead of master.
This will always lead to some dirty artifacts in the commit history

Existe una respuesta fácil a qué perspectiva es mejor, o es de alguna manera caso por caso?

Seguimient: ¿Usar "git pull --rebase" en lugar de solo "git pull" cambiaría la respuesta? La reformulación puede tener supropi trampas en algunos casos, pero hasta ahora supongo que tener un árbol / índice de trabajo sucio no haría que un rebase sea más problemático de lo que sería de otra manera.