cambiar - git config username and password

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

Question

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

1. Establecer core.autocrlf en false todas partes,

2. Sigue las instrucciones here (reflejadas en las páginas de ayuda de GitHub) para convertir el repositorio para que contenga solo los finales de línea LF, y luego establece core.autocrlf en Windows e core.autocrlf en OS X. El problema al hacer esto es que si tengo alguno archivos binarios en el repositorio que:

   1. no están correctamente marcados como binarios en gitattributes, y
   2. Sucede que contienen tanto CRLF como LF,

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

Entonces, ¿por qué no debería simplemente desactivar la conversión de fin de línea de Git? Hay muchas advertencias vagas en la web sobre tener core.autocrlf desactivado causando problemas, pero muy pocos específicos ; lo único que he encontrado hasta ahora es que kdiff3 no puede manejar los finales 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 tengo que preocuparme por compartirlo con personas con diferentes configuraciones de autocrlf o requisitos de final de línea.

¿Hay algún otro problema con el solo hecho de dejar los finales de línea como es que no conozco?

Answer 1

Las únicas razones específicas para establecer autocrlf en true son:

• evite el git status muestra todos sus archivos como modified debido a la conversión automática de EOL realizada al clonar un repositorio de EOL Git basado en Unix a uno de Windows (vea el problema 83 por ejemplo)
• y sus herramientas de codificación de alguna manera dependen de que un estilo EOL nativo esté presente en su archivo:
  • por ejemplo, un generador de código codificado para detectar EOL nativo
  • otros lotes externos (externos a su repositorio) con expresiones regulares o código establecido para detectar EOL nativos
  • Creo que algunos complementos de Eclipse pueden producir archivos con CRLF independientemente de la plataforma, lo que puede ser un problema.

A menos que pueda ver un tratamiento específico que deba lidiar con la EOL nativa, es mejor dejar autocrlf en false .

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

Si desea la misma configuración para todos los usuarios que clonan ese repositorio, consulte " ¿Cuál es la mejor estrategia de manejo de CRLF con git? ", Usando el atributo de text en el archivo .gitattributes .

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

Answer 2

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 hazlo tan pronto como puedas en la vida de tu Repositorio.

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

Lo que sucederá si no tiene todos los desarrolladores establecidos en verdadero, es que UN desarrollador eventualmente establecerá en verdadero. Esto comenzará a cambiar los finales de línea de todos sus archivos a LF en su repositorio. Y cuando los usuarios configurados en falso verifiquen esos, Visual Studio le avisará y le pedirá que los cambie. Tendrás 2 cosas que suceden muy rápido. Primero, recibirás más y más de esas advertencias, cuanto más grande sea tu equipo, más obtendrás. Lo segundo, y peor, es que mostrará que todas las líneas de cada archivo modificado fueron cambiadas (porque el final de cada línea será cambiado por el verdadero tipo). Eventualmente, ya no podrá seguir los cambios en su repositorio de manera confiable. Es MUCHO más fácil y limpio hacer que todos se mantengan fieles a la realidad, que tratar de mantenerlos falsos. Tan horrible como es vivir con el hecho de que su fuente de control de confianza está haciendo algo que no debería. Siempre.

Answer 3

Actualización :

Nota: Como lo señaló VonC, a partir de Git 2.8, los marcadores de fusión no introducirán los finales de línea de estilo Unix en un archivo de estilo Windows .

Original :

Un pequeño problema que he notado con esta configuración es que cuando hay conflictos de combinación, las líneas que git agrega para marcar las diferencias no tienen los finales de línea de Windows, incluso cuando el resto del archivo sí, y puede terminar. con un archivo con finales de línea mixtos, 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 (me imagino que cualquier herramienta que pueda manejar ambos tipos de finales de línea también se ocupará de los finales de línea mixtos, ciertamente todos los que usamos lo hacen), pero es algo que debemos tener en cuenta.

La otra cosa que hemos encontrado es que cuando se usa git diff para ver los cambios en un archivo que tiene los 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".}