Perché git mostra un conflitto tra due file aggiunti apparentemente identici?

Question

Ho un progetto che è stato avviato in TFS, quindi spostato in Git. Sfortunatamente, il tizio che l'ha spostato in Git ha appena controllato i file correnti invece di usare git-tfs. Sto cercando di ribattere i suoi nuovi commit in Git sopra i commit che ho preso da TFS usando git-tfs.

Per fare ciò, sto semplicemente ribadendo i suoi commit in cima ai commit git-tfs. (Mi rendo conto che questo rovinerà le filiali Git remote, ma siamo una piccola squadra e andrà tutto bene. Ho anche provato il cherry-picking, ma ho avuto lo stesso problema.)

Il problema I ' sto funzionando in è una serie di conflitti che assomigliano a questo:

<<<<<<< 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. 

sembra che questo è un conflitto tra un commit dal lato TFS che ha aggiunto questi file, e un commit sul lato Git che li aggiunto (come il repository Git è iniziato vuoto).

La cosa logica sarebbe saltare questo commit, forse, ma ci sono alcuni file in esso (diciamo dieci su un paio di centinaia) che sono nuovi. Quelli non causano conflitti, ovviamente.

Perché Git non riesce a capire da solo che i due file sono identici? Anche se uso --ignore-whitespace quando rebase, Git mostra ancora dozzine di file come questo che sembrano identici. Sono in perdita per come risolvere questo.

Answer 1

Dovrebbe trattarsi di differenze di fine riga, come ebneter commenti.
Ho già descritto molto tempo fa come git merge non era bravo a ignorare queste differenze (in contrasto con gli spazi bianchi differenze):
"Is it possible for git-merge to ignore line-ending differences?"

Questo è il motivo per cui un coerente politica di riconversione EOL è necessario per quei repository su un ambiente eterogeneo.
Vedere "Distributing git configuration with the code".

Answer 2

Sto facendo una cosa simile e ho appena scoperto "-X ignore-space-at-eol". È disponibile sia per l'unione che per il rebase. Sembra che stia facendo la cosa giusta, ma per me la morte è lenta.

Answer 3

Mi sono imbattuto in questo problema, seguito da questo post solo per rendermi conto che anche per me è uno scenario di fine linea.

Quindi FWIW, questo è successo nel mio caso perché avevo "Use Windows style line endings", ma a un certo punto, per un progetto diverso, l'ho riconfigurato su "Use Unix style line endings" (queste configurazioni sono disponibile dal programma Git Setup).

Tornando alla "fine riga stile Usa Windows" risolto il problema senza utilizzare "--ignore-spazio bianco"

Answer 4

Se si può escludere cambiamenti invisibili a causa di diversi finali di linea, si consiglia di verificare se i file hanno diverse modalità (es. se il bit eseguibile è impostato). Git mostra il file completo in una diff quando cambia la modalità del file.