¿Por qué los DVCS parecen tener una fobia irracional de cambios no comprometidos?

Viniendo de un fondo SVN, una de las cosas más difíciles de acostumbrar cuando se trabaja con sistemas DVCS es la forma en que todos parecen considerar cualquier cambio no comprometido como una bomba de tiempo.

En Mercurial, si intenta obtener cambios y tiene cambios no confirmados en su copia de trabajo, debe saltar a través de los aros para que solo combine los cambios entrantes. ¿Intenta cambiar de rama? Te obligará a archivar todo y luego tendrás que deshacerlo inmediatamente en el otro extremo. (SVN no tiene problemas con ninguno de estos escenarios).

Git es casi de la misma manera. Estoy trabajando lado a lado con otro desarrollador en un proyecto, y solo intenté elegir uno de sus compromisos en mi tenedor. Se negó a permitirme porque he realizado cambios no confirmados en mi copia de trabajo, en archivos completamente diferentes a los que cambió en su confirmación. Ni siquiera hay una opción de fusión; aparentemente tengo que esconder mis cambios primero!

Si una persona tratara algo completamente inofensivo con tanta precaución, lo llamaría una "fobia", un miedo irracional que debería considerarse como un trastorno mental. Pero Git y Mercurial fueron diseñados por dos equipos diferentes de desarrolladores inteligentes y racionales, por lo que me pregunto si saben algo de lo que no estoy al tanto.

¿Existe alguna razón técnica que justifique esta actitud hacia cambios no comprometidos? Y si es así, ¿por qué el problema en cuestión solo parece existir en DVCSes?

1. En DVCS, los compromisos mundiales son baratos y la historia es mutable. WIP puede ser tan "sucio" como desee: y no puedo ver ninguna razón contra "abandonar mi estado actual en el conjunto de cambios para almacenar"
2. El historial de SVN es lineal, por lo tanto, debe fusionar sus borradores con los cambios de las nuevas revisiones. El uso de DVCS (naturalmente) DAG, y la cabeza adicional (commit + pull + up) para la historia divergente es más segura, que la fusión sobre la marcha del directorio de trabajo modificado con cambios externos recuperados
3. Cuando cambia (a algún nodo ) WC modificado en Subversion, se deshace de una posible fusión adicional (al contrario de "commit to old" - "switch" - "merge 1 rev. Range") ... y sabemos: fusiones en SVN no son el lado perfecto de la herramienta, aunque no es un problema en absoluto para DVCSes

Currículum

No es una fobia, es (a veces dura) la aplicación a continuación de las buenas costumbres "cometen a menudo" (SVN usuarios a veces tienen miedo de este estilo)

Y, por fin, hg qnew|qpop|qpushes un pequeño precio justo por orden y orden

Cuando se fusiona o selecciona git, está creando una confirmación de inmediato. La operación no se completa hasta que se completa esa confirmación y forma parte del historial.

Ahora, ¿qué pasaría si gitle permitiera pasar por alto sus cambios no confirmados en su directorio de trabajo? Tendría un (más o menos) difícil momento para diferenciar entre los conflictos de cambios / fusión que necesita resolver para la fusión / selección de cereza, y los cambios que usted mismo introdujo. Además, sería casi imposible para usted probar lo que realmente está cometiendo.

Por lo tanto, forzar un directorio de trabajo limpio para las situaciones de fusión ayuda a mantener las cosas simples y manejables. Después de todo, todo lo que necesita hacer es esconder sus cambios no confirmados antes de la fusión, y desestimarlos después. Tenga en cuenta que en el flujo de trabajo

git stash
git pull
git stash pop

tiene dos (!) operaciones de fusión. Uno que combina su último compromiso con los cambios entrantes, y otro que combina sus cambios no confirmados con el compromiso de fusión resultante. De esta manera, solo necesita fusionar dos cosas en una, evitando la confusión que resultaría de tratar de fusionar tres cosas en una sola operación mientras intenta ignorar estas tres cosas. El git stash/ git stash pophace que sea fácil y explícito que está ignorando los cambios no confirmados para la fusión.