¿Por qué cambió el comportamiento de git pull en relación con los cambios de copy de trabajo?

Quiero hacer cambios en mi copy de trabajo pero git no me deja, obtengo el mismo error que esta pregunta :

Cannot rebase: Your index contains uncommitted changes. Please commit or stash them. 

Sé que puedo comprometerme y luego fusionarme, o esconder – luego tirar – y luego aplicar el alijo, pero anteriormente una extracción fusionaría los cambios en mi copy de trabajo preservando mis cambios locales. Fue perfecto, cualquier conflicto se marcaría para que lo resolviera en mi copy de trabajo, al igual que cuando se fusionan los cambios comprometidos. Me pareció muy conveniente, ¿por qué ha cambiado este comportamiento? ¿Y cómo puedo hacer que git se comporte así nuevamente?

Parece que has configurado git para siempre hacer un git pull --rebase . Hay múltiples configuraciones que conducen a este comportamiento. Citaré de la documentation :

Ver pull.rebase , branch.<name>.rebase y branch.autosetuprebase en git-config si quieres hacer que git pull use siempre –rebase en lugar de fusionar.

Si desea que Git fusione sus cambios en lugar de volver a basarlos cuando tira, tiene que encontrar la configuration culpable y deshabilitarla.

Si la configuration de pull.rebase estuviera habilitada globalmente, por ejemplo, podría deshabilitarla con el siguiente command:

 git config --global --unset pull.rebase 

No se puede rebase

Eso significa que no solo estás tirando. estás haciendo un pull --rebase .
(O, como Zeeker menciona en los comentarios , tienes configurado git para hacer siempre un pull --rebase , por ejemplo, a través de git config pull.rebase true )

Y si quiere esconder automáticamente (y volver a aplicar) su trabajo en progreso, puede verificar si funciona (Git 2.0.1+, julio de 2014) a:

 git config rebase.autostash true 

Ver más con " Git: cómo editar la confirmación anterior (no anterior) con algunos de los cambios no evaluados del índice actual (estado actual)? "