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

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.Perché git mostra un conflitto tra due file aggiunti apparentemente identici?

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.

fonte

2012-03-30 Ryan Lundy

Does 'diff' ti dà una differenza pure? – Reactormonk

Possono esserci differenze di fine linea? – ebneter

Trailing whitespaces, forse –

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

fonte

2012-03-30 22:44:48 VonC

Git considera davvero le differenze di fine riga distinte dalle differenze di spazi bianchi !? Pensavo che i finali di linea * fossero * spazi bianchi! –

@Kyralessa: non esattamente. http://gitster.livejournal.com/28862.html cita 'cr-at-eol': con' trailing-space', non si innesca se il carattere prima di un tale carriage-return non è uno spazio bianco, ma è * non attivato di default *. – VonC

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.

fonte

2012-04-14 19:22:36 dpiskyulev

Forse hanno trovato un aumento di velocità, perché per me l'aggiunta della bandiera non mi rallenta. git versione 1.9.5.msysgit.0 – AnneTheAgile

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"

fonte

2012-06-11 00:00:31 AVIDeveloper

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.

fonte

2015-02-20 13:52:47 Alexander

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

risposta

Problemi correlati