git & Cygwin – el espacio en blanco al final causa "no actualización"

Git en Windows con Cygwin está plagado de peligros. Sin embargo, hay uno que realmente está empezando a molestarme.

Está relacionado con el core.autocrlf = verdadero comportamiento. Después de pasar una semana rastreando la networking, quedó claro que los problemas que encontrará son less graves con este set. Sin embargo, si un file tiene una línea con espacios en blanco al final, parece crear un problema importante.

El problema es que git cree que el file tiene modificaciones locales, aunque no es así. Por ejemplo, después de un nuevo clon fresco, un 'estado de git' o 'git diff' mostrará inmediatamente cualquier file como modificado. A 'git reset –hard' hace lo suyo, pero esos files aún se muestran como modificados. 'git diff' muestra las diferencias como "una línea vacía eliminada, una línea vacía agregada".

¡El problema es que esto bloquea un jalón!

$ git pull Updating 73bcc56..dba6253 error: Entry 'foo.py' not uptodate. Cannot merge. $ git reset --hard HEAD is now at 73bcc56 ... $ git diff diff --git a/foo.py b/foo.py index 4cc3854..ccde3f6 100644 --- a/foo.py +++ b/foo.py @@ -14,7 +14,7 @@ class TestHelpFunctions(unittest.TestCase): def testVersion(self): v = sendCommand("version") self.assertEqual(len(v), 2) - + 

Ok, creo, hay un cambio local en el path. ¿Qué pasa si lo escondo? No, después de esconder git aún muestra este file como cambiado localmente.

Ok, ¿y si lo agrego? Por supuesto, esto todavía bloquea un tirón:

 $ git add foo.py $ git pull Updating 73bcc56..dba6253 error: Entry 'foo.py' would be overwritten by merge. Cannot merge. 

Ok, un último bash, vamos a cometerlo y terminar con eso. Oh genial, está en conflicto en este file. Pero lo sorprendente es que el file no tiene marcadores de conflicto. Desafortunadamente, 'git pull' ahora se queja de que estoy en medio de una fusión conflictiva, aunque no haya ningún conflicto marcado.

La solución, descubrí, es nunca comprometer un file con espacios en blanco al final antes de una nueva línea. Simplemente hace que git piense que el file se modifica cuando no es así, probablemente debido a la lógica de final de línea DOS-UNIX que obviamente está rota.

De todos modos, realmente no estoy buscando una respuesta, porque al final acabo de desmantelar todo y recloned. Lo que realmente me gustaría saber es cómo alguien mantiene su cordura al intentar usar git con Cygwin.

No me hagas comenzar a 'git add foo / a foo / b FOO / c' cuando el directory se llame "FOO" …

En mi experiencia, todos mis files usan el estilo UNIX eol, y siempre configuré el core.autocrlf como falso.
Vea esta respuesta SO

Cualquier cosa que ocurra " automágicamente ", especialmente en un entorno distribuido (donde no se puede garantizar la misma configuration en los repositorys remotos) es un problema.

Básicamente, si sus herramientas (como la que se utiliza para fusionar ) están configuradas correctamente, manejarán cualquier problema de espacio / eol. No es Git directamente.