Cómo reparar CRLF en el repositorio de GIT para evitar conflictos de combinación

Question

Creé mi repositorio con autocrlf=true y luego realicé algunas comprobaciones y confirmaciones con autocrlf=false. Luego volvió a autocrlf=true (OS Win). Todo parecía estar bien, hasta que comencé algunas fusiones entre sucursales. Surgieron muchos conflictos de combinación, donde todo el archivo se marcó como cambiado debido a eols cambiado (supongo que eran los archivos, que fueron desprotegidos y comprometidos con autocrlf=false).

Hay un poco de historia, que vale la pena para mí, por lo que prefiero realizar algunas conversiones o correcciones con el convertido eols en lugar de crear un nuevo repositorio y comenzar una nueva vida.

Así es como entiendo autocrlf (OS Win):

caso si autocrlf=true

WorkingTree -> commit -> GITRepository 
CRLF   CRLF to LF  LF 
LF   no conv.  LF 
WorkingTree <- checkout <- GITRepository 
CRLF   LF to CRLF  LF 

caso si autocrlf=false

WorkingTree -> commit -> GITRepository 
CRLF   no conv.  CRLF 
LF   no conv.  LF 
WorkingTree <- checkout <- GITRepository 
CRLF   no conv.  CRLF 
LF   no conv.  LF 

Ahora me gustaría utilizar GIT con autocrlf=false, por lo Decidí verificar cada rama, reparar eols de archivos fuente con la utilidad EOL converter y com volver con CRLF. Lo hice, pero después de un tiempo, todavía hay algunos archivos, que probablemente no fueron revisados ​​después de cambiar la configuración de autocrlf a false (¿o estos archivos vinieron a fusionarse de confirmaciones antiguas no corregidas? Durante la conversión usé la máscara * .filetype para automatizar el procesamiento de todas las LF a CRLF por lo que no hay otra explicación para esa situación para mí). También traté de touch los archivos, para volver a comprometerlos todos (como he visto en algún lugar aquí en stackoverflow) pero el cambio de fecha no es relevante para GIT AFAIK. También he leído How to undo the damage of autocrlf, pero no estoy seguro de que sea mi caso, y tampoco entiendo los trucos del asistente.

¿Cómo puedo alejarme de este lío, por favor?

Answer 1

Use la opción git merge "ignore-space-change" o "ignore-all-space" para la estrategia "recursiva". Esta opción está en 1.7.4.1, al menos.

Answer 2

Respuesta fácil: A menos que esté realizando el desarrollo de plataforma x con un sistema que no sea Windows, configúrelo como falso. No es necesario que su control de fuente bastardice sus archivos por usted. Después de solucionar cualquier problema restante, deberías estar volando. Asegúrese de que los demás que trabajan con usted también establezcan esto en falso.