Preparar un Windows Git Repo para el desarrollo multiplataforma

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:

  • Configurar algún tipo de enlace de precompromiso que rechace cualquier confirmación con cambios que consisten únicamente en nuevas líneas reescritas.
  • Proteger solo esos pocos files que pueden ser sensibles a los cambios de nueva línea (files .sln, .vc *, etc.).
  • Averigüe qué editores usa su equipo y asegúrese de que todos los tengan configurados para que no reestructuren falsamente las líneas nuevas. (La mayoría de los editores ya están configurados de esta manera por defecto, por lo que no tendrás problemas hasta que alguien se encargue de que el editor los reescriba).