Tengo un repository de Git que hasta ahora se usaba principalmente para el desarrollo de Windows. La mayoría de los aspectos de los problemas de EOL de GIT (LF vs. CRLF) no fueron significativos y el desarrollo se desarrolló sin obstáculos.
Habiendo pasado a un entorno de compilation CMake, quiero build el código en UNIX / Linux / MacOS. El código en sí es portátil, pero a partir de experiencias pasadas y algunos experimentos iniciales, la transición es algo dolorosa cuando Git marca directorys integers en files no modificados como modificados, detecta líneas aparentemente no modificadas dentro de files y atormenta nombres de file / carpeta confidenciales.
Además, parece que a partir de Git 1.7.2 , Git tiene un nuevo sistema EOL basado en el local, por proyecto, registrado, .gitattributes lugar de, por usuario, global, .gitattributes que cada uso en cada plataforma debe establecer.
¿Alguien puede sugerir una ruta / process de preparación de repository (en Windows) que me permita extraer y confirmar los files en Linux sin todos estos problemas?
Se pueden ver sugerencias parciales, por ejemplo aquí , pero eso es demasiado fuerza bruta y no toma en count los files que el .gitattributes específicamente tiene la intención de dejar como está (ej. *.sln )
Uso Notepad2, con eso puedes cambiar los Line Endings por defecto a Linux (LF).
Si entiendo correctamente, no hay una necesidad real de cambiar los files de origen para tener LF en máquinas con Windows. Aunque Git los comtesting con LF, se pueden consultar con CRLF en Windows.
Para mí, este es un gran no, no. Cuando uso git, quiero verificar exactamente qué hay en el repository. No veo ninguna razón para que git convierta terminaciones de línea cuando cualquier editor de text decente de Windows te permita elegir los finales de línea pnetworkingeterminados. No tolero y no permitiré que Git se meta con Line Endings.
En general, no convierta datos automáticamente antes de almacenarlos en un VCS (autocrlf = false en git IIRC), de lo contrario obtendrá falsos positivos sobre los datos que han cambiado cuando no lo hizo. Deje cualquier "interpretación" de lo que los datos significan a las herramientas fuera del VCS (editor, etc.).
Para evitar cambios espurios en la nueva línea, considere: