2011-08-25 13 views
11

Ho creato il mio repository con autocrlf=true e quindi effettuato alcuni checkout e commit con autocrlf=false. Quindi tornare a autocrlf=true (Win OS). Tutto sembrava essere OK, fino a quando ho iniziato alcune fusioni tra i rami. Molti conflitti di unione sono sorti, in cui l'intero file è stato contrassegnato come modificato a causa della modifica eols (suppongo che si trattasse di quei file, che sono stati controllati e impegnati con autocrlf=false).Come riparare CRLF nel repository GIT per evitare conflitti di unione

C'è un po 'di cronologia, che vale per me, quindi preferisco fare qualche conversione o aggiustamento dei commit con il convertito eols piuttosto che creare un nuovo repository e iniziare una nuova vita.

Ecco come ho capito autocrlf (OS Win):

caso se autocrlf=true

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

caso se autocrlf=false

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

Ora vorrei usare GIT con autocrlf=false, così Ho deciso di controllare ogni ramo, riparare eols di file di origine con l'utilità EOL converter e com mit back with CRLF. L'ho fatto, ma dopo un po 'ci sono ancora alcuni file, che probabilmente non sono stati ritirati dopo aver cambiato l'impostazione di autocrlf in false (o questi file sono venuti per unire da vecchi commit non fissi? Durante la conversione ho usato mask * .filetype in automatizza l'elaborazione di tutti i file da LF a CRLF quindi non c'è altra spiegazione per tale situazione per me). Ho provato anche a touch i file, per ri-impegnarli tutti (come ho visto da qualche parte qui in StackOverflow) ma il cambio di data non è rilevante per GIT AFAIK. Ho anche letto How to undo the damage of autocrlf, ma non sono sicuro che sia il mio caso, e inoltre non capisco i trucchi del mago.

Come posso uscire da questo casino, per favore?

+0

hai provato 'autocrlf = input'? se il tuo repository non è stato reso pubblicamente disponibile puoi usare quello e 'filter-branch --index-filter' per ripulire le terminazioni di linea nella tua cronologia – knittl

+1

@knittl: Se capisco, questo riscriverà tutti i commit nella cronologia con LF. Ho ragione? Quindi dovrò probabilmente girare 'autocrlf = true' per ottenere' CRLF' dopo il checkout (OS Win). Esiste un'opzione per convertire il repository direttamente in 'CRLF' e lasciare' autocrlf = false' dopo quello? – Andik

+0

una volta che il repository viene convertito in CRLF dovresti essere in grado di avere 'autocrlf = false' quindi nessuna terminazione di riga viene convertita e rimane come nel file – knittl

risposta

1

Utilizzare l'opzione git merge "ignore-space-change" o "ignore-all-space" per la strategia "ricorsiva". Questa opzione è in 1.7.4.1, almeno.

-2

Risposta facile: A meno che non si stia eseguendo x-platform dev con non Windows, impostare su false. Non è necessario che il tuo controllo del codice sorgente blocchi i tuoi file per te. Dopo aver risolto eventuali problemi rimanenti dovresti volare. Assicurati che anche gli altri che lavorano con te lo impostino su falso.

+2

Suggerisco di avere questa opzione SEMPRE su true su Windows - se non lo farai, avrai molti problemi con altre piattaforme. – Charminbear

Problemi correlati