¿Qué finales de línea se utilizan al escribir en el repository de git real?

Para un gran repository existente que contiene terminaciones de línea inconsistentes y codificaciones de files con ascii y UTF-8 (con BOM) …

La key es que el set actual de files es bastante inconsistente. Varían en encoding. (Vamos a ignorar UTF-16 por ahora, aunque también tengo algunos de ellos). Varían en las terminaciones de línea de un file a otro, y varían también en los finales de línea dentro de los files, aunque sospecho que la mayoría de ellos están almacenados con terminaciones de línea crlf en git.

Hay dos problemas principales aquí:

1) Diferentes personas que usan los mismos repositorys pueden ver los cambios y ven un set diferente de cambios. A veces, el "file completo" se ha modificado debido a las terminaciones de línea normalizadas. A veces solo se ha cambiado una parte del file. Esto parece depender principalmente de si core.autocrlf se ha configurado como verdadero o falso, y también parece estar influenciado por el uso de un file .gitattributes.

2) Quiero que todas las personas puedan enviar files al repository de git, sin tener que prestar mucha atención a si su configuration particular de git ha sido configurada para hacer la conversión crlf, o su editor de text, IDE o cualquier herramienta que hayan decidido utilizar. (Tan roto como este comportamiento puede ser en Windows, tenemos que vivir con eso …)


La pregunta principal es esta: ¿Cómo puedo estar seguro de que la salida mostrada por 'gitk', 'git diff', 'git show' y similares son absolutamente consistentes con respecto a los cambios que se muestran. Estoy less preocupado por las terminaciones de línea aquí, y más para asegurar que el 'cambio' para un compromiso determinado sea el mismo cambio visto por todos los desarrolladores. No quiero que una persona mire un cambio y vea "todas las líneas han cambiado" (es decir, las terminaciones de línea cambiaron), mientras que otra persona ve el mismo cambio, y dice: "tres líneas han cambiado".

  • Nota: Algunas personas usan github para ver los cambios.

Dicho esto, quiero tener confianza en saber cómo se ven afectadas las terminaciones de línea, así que en última instancia estoy preguntando cómo saber qué ocurre con los finales de línea. Si, por ejemplo, especifico "eol = crlf" para un file dado en .gitattributes, ¿eso significa que el file está comprometido a git con esa configuration? ¿Y qué sucede si reviso una versión anterior de ese file que se haya confirmado antes de establecer ese file .gitattributes?

Ok, esto es lo que está pasando:

Primero: las diferencias siempre se ven iguales y no dependen de la configuration de git local. Puedes intentar eso: git diff HEAD^ HEAD se verá igual en todas tus máquinas (suponiendo que tengan la misma HEAD).

Pero ¿por qué las diferencias se ven diferentes en sus máquinas, entonces? Supongamos que tiene un file en su repository que se ve exactamente así:

 two \r\n lines 

El check out se verá así en todas las máquinas. Pero en el check in hay dos opciones:

  1. La normalización de finalización de línea está activada. El file ahora se registrará como:

     two \n lines 

    y git diff informará que habrá un cambio

  2. La normalización de finalización de línea está desactivada. El file se registrará como:

     two \r\n lines 

    y git diff no informará ningún cambio.


Ahora, ¿cómo puedes asegurarte de que todos vean los mismos cambios? Recomendaría habilitar la normalización de finalización de línea para todos. Para hacer eso, crea un .gitattributes en la raíz de tu repository con este contenido:

 * text=auto 

Y confíe este file a cada twig. Una vez que todos hayan retirado este compromiso, los diffs se verán igual en todas partes.


Nota final: core.eol no tiene ningún efecto sobre esto en absoluto. Solo cambia los finales de línea en el directory de trabajo. git diff no diferencia el directory de trabajo del índice, pero diffs lo que se comprometería con el índice.

Supongo que googlearás "git line endings" para ver cómo hacer la configuration de repo básica.

No puedes influir en nada que ya esté comprometido. Lo único que puede hacer es realizar nuevos commits con cualquier contenido de file fijo que desee.

A partir de tu comentario a continuación, lo que buscas es poder ignorar por completo las diferencias de final de línea. Vea aquí y aquí las mejores respuestas anteriores de stackoverflow que pude encontrar.