¿Por qué debería usar core.autocrlf = true en Git?

Tengo un repositorio de Git al que se accede desde Windows y OS X, y que sé que ya contiene algunos archivos con terminaciones de línea CRLF. Por lo que puedo decir, hay dos formas de lidiar con esto:

1. Establecer core.autocrlfen falsetodas partes,

2. Siga las instrucciones aquí (se hizo eco en las páginas de ayuda de GitHub) para convertir el repositorio para contener solamente terminaciones de líneas LF, y posteriormente ajustado core.autocrlfa trueen Windows y inputen OS X. El problema con esto es que si tengo los archivos binarios en el repositorio ese:

   1. no están marcados correctamente como binarios en gitattributes, y
   2. puede contener CRLF y LF,

   Serán corrompidos. Es posible que mi repositorio contenga tales archivos.

Entonces, ¿por qué no debería simplemente desactivar la conversión de final de línea de Git? Hay muchas advertencias vagas en la web sobre la core.autocrlfdesconexión que causa problemas, pero muy pocas específicas ; lo único que he encontrado hasta ahora es que kdiff3 no puede manejar las terminaciones de CRLF (no es un problema para mí), y que algunos editores de texto tienen problemas de final de línea (tampoco es un problema para mí).

El repositorio es interno de mi empresa, por lo que no necesito preocuparme por compartirlo con personas con diferentes configuraciones de autocrlf o requisitos de final de línea.

¿Hay algún otro problema con solo dejar las terminaciones de línea tal como las desconozco?

Las razones específicas solamente para configurar autocrlfa trueson:

• evite git statusmostrar todos sus archivos modifieddebido a la conversión automática de EOL al clonar un repositorio EOL Git basado en Unix en uno de Windows (consulte el problema 83, por ejemplo)
• y sus herramientas de codificación de alguna manera dependen de un estilo EOL nativo presente en su archivo:
  • por ejemplo, un generador de código codificado para detectar EOL nativa
  • otros lotes externos (externos a su repositorio) con regexp o conjunto de códigos para detectar EOL nativa
  • Creo que algunos complementos de Eclipse pueden producir archivos con CRLF independientemente de la plataforma, lo que puede ser un problema.
  • Codifica con Notepad.exe (a menos que esté utilizando Windows 10 2018.09+, donde Notepad respeta el carácter EOL detectado ).

A menos que pueda ver un tratamiento específico que debe tratar con la EOL nativa, es mejor que se vaya autocrlfafalse ( git config --global core.autocrlf false).

Tenga en cuenta que esta configuración sería local (porque la configuración no se transfiere de repositorio a repositorio)

Si desea la misma configuración para todos los usuarios que clonan ese repositorio, consulte " ¿Cuál es la mejor CRLFestrategia de manejo con git? ", Utilizando el textatributo en el .gitattributesarchivo .

Ejemplo:

*.vcproj    text eol=crlf
*.sh        text eol=lf

Nota: a partir de git 2.8 (marzo de 2016), los marcadores de combinación ya no introducirán el final de línea mixta (LF) en un archivo CRLF.
Consulte " Hacer que Git use CRLF en sus líneas de fusión" <<<<<<< HEAD " "

Soy un desarrollador de .NET y he usado Git y Visual Studio durante años. Mi fuerte recomendación es establecer los finales de línea en verdadero. Y hágalo lo antes posible en la vida de su Repositorio.

Dicho esto, ODIO que Git cambie mis finales de línea. Un control de origen solo debe guardar y recuperar el trabajo que hago, NO debe modificarlo. Nunca. Pero lo hace.

Lo que sucederá si no tiene todos los desarrolladores configurados como verdaderos, es que UN desarrollador finalmente se configurará como verdadero. Esto comenzará a cambiar las terminaciones de línea de todos sus archivos a LF en su repositorio. Y cuando los usuarios se configuran como falsos, échales un vistazo, Visual Studio te advertirá y te pedirá que los cambies. Tendrás 2 cosas que suceden muy rápidamente. Uno, obtendrá más y más de esas advertencias, cuanto más grande sea su equipo, más obtendrá. La segunda, y lo peor, es que mostrará que todas las líneas de cada archivo modificado fueron cambiadas (porque las terminaciones de cada línea serán cambiadas por el tipo verdadero). Eventualmente, ya no podrá seguir los cambios en su repositorio de manera confiable. Es MUCHO más fácil y más limpio hacer que todos mantengan la verdad, que tratar de mantener a todos falsos. Tan horrible como es vivir con el hecho de que su control de fuente confiable está haciendo algo que no debería. Nunca.

Actualización 2 :

Xcode 9 parece tener una "característica" donde ignorará las terminaciones de línea actuales del archivo y, en su lugar, solo usará su configuración predeterminada de finalización de línea al insertar líneas en un archivo, lo que dará como resultado archivos con terminaciones de línea mixtas.

Estoy bastante seguro de que este error no existía en Xcode 7; no estoy seguro acerca de Xcode 8. La buena noticia es que parece estar arreglado en Xcode 10.

Por el tiempo que existió, este error causó una pequeña cantidad de hilaridad en la base de código a la que me refiero en la pregunta (que hasta el día de hoy usa autocrlf=false), y condujo a muchos mensajes de confirmación "EOL" y, finalmente, a que escribiera un pre-commitgancho git para verificar para / evitar la introducción de terminaciones de línea mixtas.

Actualización :

Nota: Como se ha señalado por VonC, a partir de Git 2.8, marcadores de combinación será no introducir estilo Unix el fin de línea en un archivo de estilo de Windows .

Original :

Un pequeño inconveniente que he notado con esta configuración es que cuando hay conflictos de fusión, las líneas que agrega git para marcar las diferencias no tienen terminaciones de línea de Windows, incluso cuando el resto del archivo sí, y puede terminar con un archivo con terminaciones de línea mixtas, por ejemplo:

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

Esto no nos causa ningún problema (imagino que cualquier herramienta que pueda manejar ambos tipos de terminaciones de línea también se ocupará de las terminaciones de línea mixtas, sin duda todas las que usamos), pero es algo a tener en cuenta.

La otra cosa ^* que hemos encontrado es que cuando se usa git diffpara ver los cambios en un archivo que tiene finales de línea de Windows, las líneas que se han agregado muestran sus retornos de carro, por lo tanto:

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

_{* Realmente no merece el término: "problema".}