Raccomandazione definitiva per le impostazioni git autocrlf

Io uso Windows, Mac OS X e Linux ogni giorno. Io uso git in tutti questi ambienti, estrapolando da repository che vengono utilizzati da persone con scelte diverse per i finali di linea.

Ci sono raccomandazioni definitive per l’impostazione di core.autocrlf nella mia situazione?

Consiglierei, come ho fatto in questa domanda SO , di impostarlo su false.

Se puoi evitare di modificare qualsiasi eol (con il tuo editor), allora sarebbe meglio respingere il tuo lavoro con quegli eol invariati (cioè “come li hai trovati”).

Un problema che spesso non viene menzionato in queste discussioni: se sviluppi script di shell su Windows (diciamo, in cygwin) e li impegni con CRLF (autocrlf = false), si bloccheranno su * nix box con messaggi di errore inutili. (Potrebbero esserci casi simili con altri linguaggi di scripting). Dopo aver grattato la testa per mezz’ora, ricorderai e poi dos2unix i piccoli mascalzoni. Se lavori in un ambiente misto (ad esempio distribuisci da Windows a un server Linux) e vuoi assolutamente impostare autocrlf su false, allora ASSICURI che tutti gli editor di windows usino terminazioni di riga unix (lf). Altrimenti, impostare autocrlf su input (e prega). La maggior parte dei programmi Windows del 21 ° secolo sono comodi senza i primi CR degli stampatori di linea degli anni ’80, quindi è una buona idea impostare comunque i finali di linea su LF (unix).

GIT NON avrebbe SHA1 comuni per due file di testo con testo identico ma diversi meccanismi di fine linea (EOL) all’interno della rappresentazione binaria. Il contenuto è memorizzato come un blob, che viene riutilizzato se un’altra copia identica è de-posizionata nel repository (risparmio di spazio!)

La scelta predefinita presa da (il) GIT (designer) è di usare il carattere EOL * nix style (solo LF) quando ansible, in modo che per lo stesso contenuto di testo si ottenga lo stesso SHA1. (probabilmente una considerazione importante 😉

Poiché il contenuto / blob non ricorda più la scelta EOL originale dell’utente (ricorda che probabilmente è ora in qualche repository distante), Git deve fare alcune ipotesi (basate su un’opzione) su come ricreare il file dell’utente originale (era CRLF o era semplicemente LF) in un modo che tu (e i tuoi strumenti) puoi usare.

La raccomandazione normale è che localmente ogni utente (a) converta in terminazioni LF * nix quando si esegue il commit in un blob (in modo che tutti vedano nomi BLOB SHA1 comuni) (a / k / a The Right Thing) e (b) localmente impostate opzione di ri-creazione per il loro sistema locale, ad esempio * nix (LF) o Windows (CRLF), ecc.

Stabilisci alcuni standard locali per i tuoi utenti e disponi di un unico “EOL / LF / CRLF & Correzione correzione spazio bianco”, e andrà tutto bene (oltre alla riqualificazione dell’allenamento di nuovi utenti)

Puoi anche assicurarti che (ogni utente) usi una comune impostazione di regolazione dello spazio bianco in modo che le tabs v spazi, e spazi vuoti finali non causino ulteriori inconvenienti!