Git core.safecrlf comportamento diverso su file con le stesse terminazioni di linea

Question

Ho una macchina Windows con progetto VS e uso sia Visual Studio che strumenti dall'ambiente Cygwin incluso Git. A volte ottengo diverse terminazioni di riga nei file dopo la modifica. Voglio una soluzione semplice per controllare la coerenza di fine riga dei file prima che vadano al repository. Git's core.safecrlf è la cosa giusta, suppongo. Ora ho uno strano comportamento:

file A e B con i seguenti parametri:

$file A 
A: HTML document, UTF-8 Unicode text, with CRLF line terminators 
$file B 
B: HTML document, UTF-8 Unicode (with BOM) text, with CRLF line terminators 

File A è già in pronti contro termine, il file B è nuova. Nota, entrambi hanno terminazioni di linea CRLF. Ora prova a metterli in scena, core.safecrlf è true.

$git add A # ok 
$git add B # fails 
fatal: CRLF would be replaced by LF in B. 

Sto usando correttamente core.safecrlf? O forse ho bisogno di scrivere hook per controllare i file?

Note:

• provato con differenti codifiche di file (con e senza BOM), nessuna differenza.
• c'è legato core.autocrlf caratteristica in Git, aggiunto ai tag (StackOverflow Nessun tag per core.safecrlf)
• git versione 1.8.5.rc1.17.g0ecd94d (compilato da fonti sotto Cygwin)

EDIT # 1: estratto core.autocrlf - era input. Modificato su false, ora posso aggiungere entrambi i file. Perché?

Answer 1

In base alla modifica successiva, core.autocrlf = input era l'impostazione originale. Con questa impostazione, CRLF viene convertito in LF quando si effettua il check-in nel repository e viene mantenuto in questo modo al momento del check-out. Ciò significa che un editor consapevole di terminazioni di riga non Unix come Blocco note potrebbe rovinare l'aspetto di una versione del file estratta. Sarebbe una gigantesca lunga fila.

FWIW core.autocrlf = input è l'impostazione preferita sui sistemi Unix e l'utilizzo della build predefinita cygwin probabilmente lo imposta in questo modo. In Windows le impostazioni consigliate è core.autocrlf = true che è quello che msysgit raccomanda

core.safecrlf = true interrompe la conversione di un file se estrarre il file si tradurrà in un file modificato ed eventualmente danneggiati, che sarebbe il caso se il Blocco note è l'editor. Questo è il motivo per cui il file B è stato interrotto perché sarebbe stato incasinato in un editor come Notepad. Va notato la differenza tra core.SAFEcrlf e core.AUTOcrlf.Si tratta di uno dei eyes glazing over problemi nella comprensione git fine riga

core.autocrlf = false è non importa modalità. Effettua il check-in e controlla i file esattamente come sono, ed è per questo che i commit funzionano ora. Questo non è molto intelligente e non è raccomandato perché causa problemi se i file vengono modificati su entrambi i sistemi Windows e Unix e anche se le impostazioni di altri utenti core.autocrlf differiscono e cambiano le terminazioni di file.

La mia preferenza è quella di impostare core.autocrlf-input su Windows se tutto Windows editor e altri strumenti di elaborazione di file di testo sul progetto sono linea di Unix che termina a conoscenza, altrimenti impostarlo su core.autocrlf = true per Windows e core.autocrlf = input per Unix. In ogni caso questo approccio è superato dal metodo superiore del file .gitattributes.

Il metodo file .gitattributes elabora i file in base al nome del file e viene mantenuto in tutti gli ambienti degli utenti poiché viene estratto nella directory di lavoro come .gitignore. Le impostazioni per tutti i nomi di file e tipi rilevanti per il progetto devono essere aggiunte a .gitattributes. La configurazione ritorna quindi alle impostazioni locali core.autocrlf e core.safecrlf se il nome del file non corrisponde a .gitattributes. L'aggiunta di * text=auto nella parte superiore di .gitattributes causerà git per fare una stima ottimale sui nomi di file che non corrispondono alle successive impostazioni .gitattributes.

Questa pagina Web, Mind the End of Your Line mi ha aiutato a capire meglio il problema. Si potrebbe leggere per ulteriori informazioni sul problema.

Answer 2

Le scelte di fine linea CR LF non sono così facili da capire. Ci sono due punti per le descrizioni in quanto è trattato sia in Git-attributes che in Git-config.

Inizialmente c'erano le impostazioni di autoclm, e poi c'erano le versioni più recenti che hanno alcune incompatibilità potenziali (cioè fare cose inaspettate come si indica).

tendo a impostare l'eol = LF, che rende tutti i file di testo impegnarsi come fine riga LF (è possibile impostare gli attributi per quanto riguarda i file che sono considerati testo) e quindi aggiungere il safecrlf per fare un controllo di andata e ritorno.