¿Por qué git muestra un conflicto entre dos archivos agregados aparentemente idénticos?

Question

Tengo un proyecto que se inició en TFS, luego se movió a Git. Desafortunadamente, el chico que lo movió a Git acaba de verificar los archivos actuales en lugar de usar git-tfs. Estoy tratando de volver a establecer las bases de sus nuevos commits en Git además de los commits que hice de TFS usando git-tfs.

Para hacer esto, simplemente estoy rehaciendo sus compromisos sobre los commits de git-tfs. (Me doy cuenta de que esto arruinará las sucursales remotas de Git, pero somos un equipo pequeño y todo irá bien. También intenté seleccionar las cerezas, pero acerté con el mismo problema.)

El problema es ' estoy corriendo en una serie de conflictos que se parece a esto:

<<<<<<< HEAD 
namespace OurNiftyProject 
{ 
    public enum CardType 
    { 
     Visa = 0, 
     MasterCard = 1 
    } 
} 
||||||| merged common ancestors 
======= 
namespace OurNiftyProject 
{ 
    public enum CardType 
    { 
     Visa = 0, 
     MasterCard = 1 
    } 
} 
>>>>>>> Add a bunch of stuff. 

parece que este es un conflicto entre una confirmación desde el lado de TFS que agrega estos archivos, y una confirmación en el lado Git que les añade (como el repositorio de Git comenzó vacío).

Lo lógico sería omitir esta confirmación, tal vez, pero hay algunos archivos (por ejemplo, diez de un par de cientos) que son nuevos. Esos no causan conflictos, por supuesto.

¿Por qué Git no puede darse cuenta de que los dos archivos son idénticos? Incluso si uso --ignore-whitespace cuando rebase, Git todavía muestra docenas de archivos como este que parecen ser idénticos. No sé cómo resolver esto.

Answer 1

Debe tratarse de diferencias de final de línea, como ebneter comentarios.
que ya han detallado hace mucho tiempo cómo git merge no era bueno en ignorar esas diferencias (en contraposición a los espacios en blanco diferencias):
"Is it possible for git-merge to ignore line-ending differences?"

Por eso es necesaria una política de conversión EOL consistente para aquellos repositorios en ambiente heterogéneo.
Ver "Distributing git configuration with the code".

Answer 2

Estoy haciendo algo similar y acabo de enterarme de "-X ignore-space-at-eol". Está disponible tanto para fusión como para rebase. Parece estar haciendo lo correcto pero hace que la muerte sea lenta para mí.

Answer 3

Acabo de tropezar con este problema, seguido por este post solo para darme cuenta de que también es un escenario de final de línea.

Así que, FWIW, esto sucedió en mi caso porque solía tener "Usar terminaciones de línea de Windows", pero en algún momento, para un proyecto diferente, lo reconfiguré a "Usar terminaciones de línea de estilo Unix" (estas configuraciones son disponible desde el programa de instalación de Git).

Volviendo a "finales de línea de estilo Uso de Windows" resuelto el problema sin utilizar "--ignore un espacio en blanco"

Answer 4

Si se puede descartar cambios invisibles debido a diferentes finales de línea, es posible que desee comprobar si los archivos tienen diferentes modos (por ejemplo, si el bit ejecutable está configurado). Git muestra el archivo completo en un diff cuando el modo de archivo cambió.