Perché dovrei usare core.autocrlf = true in Git?

Ho un repository Git a cui si accede sia da Windows che da OS X e che so già contiene alcuni file con terminazioni di linea CRLF. Per quanto ne so, ci sono due modi per affrontarlo:

1. Impostare core.autocrlfa falsetutto il mondo,

2. Seguire le istruzioni qui (eco sulle pagine di aiuto di GitHub) per convertire il repository per contenere solo LF line-finali, e successivamente impostare core.autocrlfa truesu Windows e inputsu OS X. Il problema di questa operazione è che se ho tutti i file binari nel repository quello:

   1. non sono correttamente contrassegnati come binari in gitattributes e
   2. capita di contenere sia CRLF che LF,

   saranno corrotti. È possibile che il mio repository contenga tali file.

Quindi perché non dovrei semplicemente disattivare la conversione di fine riga di Git? Ci sono molti avvisi vaghi sul web di aver core.autocrlfspento causando problemi, ma pochissimi quelli specifici ; l'unico che ho scoperto finora è che kdiff3 non è in grado di gestire le terminazioni CRLF (non è un problema per me) e che alcuni editor di testo hanno problemi di fine riga (anche per me non è un problema).

Il repository è interno alla mia azienda, quindi non devo preoccuparmi di condividerlo con persone con diverse impostazioni di autocrlf o requisiti di fine riga.

Ci sono altri problemi nel lasciare le terminazioni così come sono di cui non sono a conoscenza?

Le ragioni solo specifico per la definizione autocrlfdi truesono:

• evita di git statusmostrare tutti i tuoi file come a modifiedcausa della conversione EOL automatica fatta quando cloni un repository EOL Git basato su Unix in uno Windows (vedi il problema 83 per esempio)
• e i tuoi strumenti di codifica dipendono in qualche modo dallo stile EOL nativo presente nel tuo file:
  • ad esempio, un generatore di codice codificato per rilevare EOL nativo
  • altri batch esterni (esterni al repository) con regexp o codice impostato per rilevare EOL nativo
  • Credo che alcuni plugin Eclipse possano produrre file con CRLF indipendentemente dalla piattaforma, il che può essere un problema.
  • Si codifica con Notepad.exe (a meno che non si utilizzi Windows 10 2018.09+, in cui Notepad rispetta il carattere EOL rilevato ).

A meno che non si riesca a vedere un trattamento specifico che deve occuparsi di EOL nativo, è meglio lasciare autocrlfafalse ( git config --global core.autocrlf false).

Si noti che questa configurazione sarebbe locale (perché la configurazione non viene trasferita da repo a repo)

Se vuoi la stessa configurazione per tutti gli utenti che clonano quel repository, controlla " Qual è la migliore CRLFstrategia di gestione con git? ", Usando l' textattributo nel .gitattributesfile .

Esempio:

*.vcproj    text eol=crlf
*.sh        text eol=lf

Nota: a partire da git 2.8 (marzo 2016), i marker di unione non introdurranno più la fine della linea mista (LF) in un file CRLF.
Vedi " Fai in modo che Git usi CRLF sulle sue linee di unione" <<<<<<< HEAD "

Sono uno sviluppatore .NET e uso Git e Visual Studio da anni. La mia forte raccomandazione è di impostare le terminazioni di riga su true. E fallo il prima possibile nella vita del tuo repository.

Detto questo, ODIO il fatto che Git cambi i miei finali. Un controllo del codice sorgente dovrebbe solo salvare e recuperare il lavoro che faccio, NON dovrebbe modificarlo. Mai. Ma lo fa.

Cosa succederà se non hai tutti gli sviluppatori impostati su true, UNO sviluppatore alla fine verrà impostato su true. Questo inizierà a cambiare le terminazioni di linea di tutti i tuoi file in LF nel tuo repository. E quando gli utenti impostano il falso per controllarli, Visual Studio ti avviserà e ti chiederà di cambiarli. Avrai 2 cose che succedono molto rapidamente. Uno, riceverai sempre più di quegli avvertimenti, più grande sarà la tua squadra e più otterrai. La seconda, e la cosa peggiore, è che mostrerà che ogni riga di ogni file modificato è stata cambiata (perché la fine di ogni riga sarà cambiata dal vero ragazzo). Alla fine non sarai più in grado di tenere traccia delle modifiche nel tuo repository in modo affidabile. È MOLTO più semplice e pulito rendere tutti fedeli alla verità, piuttosto che cercare di mantenere tutti falsi. Per quanto sia orribile convivere con il fatto che il tuo affidabile controllo del codice sorgente stia facendo qualcosa che non dovrebbe. Mai.

Aggiornamento 2 :

Xcode 9 sembra avere una "caratteristica" in cui ignora i finali di riga correnti del file e utilizza invece l'impostazione di fine riga predefinita quando si inseriscono le righe in un file, risultando in file con finali di riga misti.

Sono abbastanza sicuro che questo errore non esistesse in Xcode 7; non sono sicuro di Xcode 8. La buona notizia è che sembra essere stato risolto in Xcode 10.

Per il tempo in cui è esistito, questo bug ha causato una piccola quantità di ilarità nella base di codice a cui mi riferisco nella domanda (che fino ad oggi utilizza autocrlf=false), e ha portato a molti messaggi di "EOL" e infine alla mia scrittura di un pre-commithook git per verificare per / prevenire l'introduzione di terminazioni di linea miste.

Aggiornamento :

Nota: Come notato da VonC, a partire dal Git 2.8, i marcatori di unione sarà non introdurrà stile Unix line-terminazioni in un file in stile Windows .

Originale :

Un piccolo inconveniente che ho notato con questa configurazione è che quando ci sono conflitti di unione, le linee aggiunte da git per evidenziare le differenze non hanno terminazioni di linea di Windows, anche quando il resto del file lo fa, e puoi finire con un file con terminazioni di riga miste, ad esempio:

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

Questo non ci causa alcun problema (immagino che qualsiasi strumento in grado di gestire entrambi i tipi di terminazioni di linea si occuperà anche di terminazioni di linea miste - certamente tutte quelle che usiamo fare), ma è qualcosa di cui essere consapevoli.

L'altra cosa ^* che abbiamo scoperto è che quando si utilizza git diffper visualizzare le modifiche a un file con terminazioni di linea di Windows, le linee che sono state aggiunte mostrano i loro ritorni a capo, quindi:

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

_{* In realtà non merita il termine: "problema".}