Ho provato a eseguire il commit dei file con le righe finali CRLF, ma non è riuscito.

Ho trascorso un'intera giornata di lavoro sul mio computer Windows provando diverse strategie ed ero quasi attratto da smettere di provare a usare Git e invece provare Mercurial .

Si prega di condividere solo una best practice per risposta.

Quasi quattro anni dopo aver fatto questa domanda, ho finalmente trovato una risposta che mi soddisfa completamente !

Vedi i dettagli in github: guida di aiuto per gestire le terminazioni di linea .

Git ti permette di impostare le proprietà di fine riga per un repository direttamente usando l' attributo text nel .gitattributesfile. Questo file viene inserito nel repository e sovrascrive l' core.autocrlfimpostazione, consentendo di garantire un comportamento coerente per tutti gli utenti indipendentemente dalle loro impostazioni git.

E quindi

Il vantaggio di questo è che la tua configurazione di fine linea ora viaggia con il tuo repository e non devi preoccuparti se i collaboratori hanno le impostazioni globali adeguate.

Ecco un esempio di un .gitattributesfile

# Auto detect text files and perform LF normalization
*        text=auto

*.cs     text diff=csharp
*.java   text diff=java
*.html   text diff=html
*.css    text
*.js     text
*.sql    text

*.csproj text merge=union
*.sln    text merge=union eol=crlf

*.docx   diff=astextplain
*.DOCX   diff=astextplain

# absolute paths are ok, as are globs
/**/postinst* text eol=lf

# paths that don't start with / are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf

Esiste una comoda raccolta di file .gitattributes pronti all'uso per i linguaggi di programmazione più diffusi. È utile per iniziare.

Dopo aver creato o modificato il tuo .gitattributes, dovresti eseguire una nuova normalizzazione dei finali di riga una volta per tutte .

Nota che l' app desktop GitHub può suggerire e creare un .gitattributesfile dopo aver aperto il repository Git del progetto nell'app. Per provarlo, fai clic sull'icona a forma di ingranaggio (nell'angolo in alto a destra)> Impostazioni repository ...> Fine riga e attributi. Ti verrà chiesto di aggiungere il suggerito .gitattributese, se sei d'accordo, l'app eseguirà anche una normalizzazione di tutti i file nel tuo repository.

Infine, l'articolo Mind the End of Your Line fornisce ulteriori informazioni e spiega come Git si è evoluto sulle questioni a portata di mano. Considero questa lettura obbligatoria .

Probabilmente hai utenti del tuo team che usano EGit o JGit (strumenti come Eclipse e TeamCity li usano) per eseguire il commit delle loro modifiche. Quindi sei sfortunato, come ha spiegato @gatinueta nei commenti di questa risposta:

Questa impostazione non ti soddisferà completamente se hai persone che lavorano con Egit o JGit nel tuo team, poiché quegli strumenti ignoreranno semplicemente .gitattributes e controlleranno felicemente i file CRLF https://bugs.eclipse.org/bugs/show_bug.cgi? id = 342.372

Un trucco potrebbe essere quello di farli impegnare le loro modifiche in un altro client, ad esempio SourceTree . Il nostro team di allora ha preferito questo strumento a EGit di Eclipse per molti casi d'uso.

Chi ha detto che il software è facile? : - /

Non convertire le terminazioni di riga. Non è compito del VCS interpretare i dati, ma solo archiviarli e versioni. Ogni moderno editor di testi può comunque leggere entrambi i tipi di terminazioni di riga.

Quasi sempre vuoi a autocrlf=inputmeno che tu non sappia davvero cosa stai facendo.

Qualche ulteriore contesto di seguito:

Dovrebbe essere o core.autocrlf=truese ti piace la desinenza DOS o core.autocrlf=inputse preferisci unix-newline. In entrambi i casi, il tuo repository Git avrà solo LF, che è la cosa giusta. L'unico argomento core.autocrlf=falseera che l'euristica automatica potrebbe erroneamente rilevare alcuni file binari come testo e quindi il riquadro verrà danneggiato. Quindi, è core.safecrlfstata introdotta l'opzione per avvisare un utente se si verifica un cambiamento irreversibile. In effetti, ci sono due possibilità di cambiamenti irreversibili: la fine della linea mista nel file di testo, in questa normalizzazione è auspicabile, quindi questo avviso può essere ignorato o (molto improbabile) che Git abbia erroneamente rilevato il tuo file binario come testo. Quindi devi usare gli attributi per dire a Git che questo file è binario.

Il paragrafo precedente è stato originariamente estratto da un thread su gmane.org, ma da allora è andato in giù.

Due strategie alternative per essere coerenti con le terminazioni di linea in ambienti misti (Microsoft + Linux + Mac):

A. Impostazione globale per tutti i repository

1) Converti tutto in un formato

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) Set core.autocrlfdi inputsu Linux / UNIX o truesu MS Windows (repository o globale)

git config --global core.autocrlf input

3) [Opzionale] impostato core.safecrlfsu true(per interrompere) o warn(per cantare :) per aggiungere un ulteriore controllo rispetto se la trasformazione della nuova riga invertita comporterebbe lo stesso file

git config --global core.safecrlf true

B. O per impostazione del repository

1) Converti tutto in un formato

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) aggiungi il .gitattributesfile al tuo repository

echo "* text=auto" > .gitattributes
git add .gitattributes
git commit -m 'adding .gitattributes for unified line-ending'

Non preoccuparti dei tuoi file binari: Git dovrebbe essere abbastanza intelligente su di loro.

Ulteriori informazioni sulle variabili safecrlf / autocrlf

Prova a impostare l' core.autocrlfopzione di configurazione su true. Dai anche un'occhiata core.safecrlfall'opzione.

In realtà sembra che core.safecrlfpotrebbe essere già impostato nel tuo repository, perché (sottolineatura mia):

In caso contrario, per l'impostazione corrente di core.autocrlf, git rifiuterà il file .

In questo caso, potresti voler verificare che il tuo editor di testo sia configurato per utilizzare le terminazioni di riga in modo coerente. Probabilmente si verificheranno problemi se un file di testo contiene una combinazione di terminazioni di riga LF e CRLF.

Infine, ritengo che la raccomandazione di utilizzare semplicemente "ciò che ti viene dato" e utilizzare le linee terminate LF su Windows causerà più problemi di quanti ne risolva. Git ha le opzioni di cui sopra per provare a gestire le terminazioni di linea in modo ragionevole, quindi ha senso usarle.

L'utilizzo ha core.autocrlf=falseimpedito che tutti i file vengano contrassegnati come aggiornati non appena li ho estratti nel mio progetto Visual Studio 2010 . Anche gli altri due membri del team di sviluppo utilizzano i sistemi Windows, quindi non è entrato in gioco un ambiente misto, tuttavia le impostazioni predefinite fornite con il repository hanno sempre contrassegnato tutti i file come aggiornati immediatamente dopo la clonazione.

Immagino che la linea di fondo sia trovare quale impostazione CRLF funziona per il tuo ambiente. Soprattutto dal momento che in molti altri repository le nostre impostazioni di scatole Linux autocrlf = trueproducono risultati migliori.

20+ anni dopo e stiamo ancora affrontando le disparità di fine linea tra i sistemi operativi ... triste.

Queste sono le due opzioni per gli utenti Windows e Visual Studio che condividono il codice con utenti Mac o Linux . Per una spiegazione estesa, leggi il manuale di gitattributes .

* testo = auto

Nel .gitattributesfile del tuo repository aggiungi:

*   text=auto

Ciò normalizzerà tutti i file con LFterminazioni di riga nel repository.

E a seconda del sistema operativo ( core.eolimpostazione), i file nella struttura di lavoro verranno normalizzati LFper i sistemi basati su Unix o CRLFper i sistemi Windows.

Questa è la configurazione utilizzata dai repository di Microsoft .NET .

Esempio:

Hello\r\nWorld

Verrà normalizzato nel repository sempre come:

Hello\nWorld

Al momento del pagamento, l'albero di lavoro in Windows verrà convertito in:

Hello\r\nWorld

Al momento del checkout, l'albero di lavoro in Mac verrà lasciato come:

Hello\nWorld

Nota: se il tuo repository contiene già file non normalizzati, git statusmostrerà questi file come completamente modificati alla successiva modifica, e potrebbe essere una seccatura per gli altri utenti unirli in seguito. Vedere l' aggiornamento di un repository dopo aver modificato le terminazioni di riga per ulteriori informazioni.

core.autocrlf = true

Se textnon è specificato nel .gitattributesfile, Git utilizza la core.autocrlfvariabile di configurazione per determinare se il file deve essere convertito.

Per gli utenti Windows, git config --global core.autocrlf trueè un'ottima opzione perché:

• I file vengono normalizzati per LFterminare le righe solo quando vengono aggiunti al repository. Se nel repository sono presenti file non normalizzati, questa impostazione non li toccherà.
• Tutti i file di testo vengono convertiti in CRLFterminazioni di riga nella directory di lavoro.

Il problema con questo approccio è che:

• Se sei un utente Windows con autocrlf = input, vedrai un mucchio di file con LFterminazioni di riga. Non è un pericolo per il resto della squadra, perché i tuoi commit saranno comunque normalizzati con le LFterminazioni di linea.
• Se sei un utente Windows con core.autocrlf = false, vedrai un mucchio di file con LFterminazioni di riga e puoi introdurre file con CRLFterminazioni di riga nel repository.
• La maggior parte degli utenti Mac utilizza autocrlf = inpute potrebbe ottenere file con CRLFterminazioni di file, probabilmente da utenti Windows con core.autocrlf = false.

--- UPDATE 3 --- (non è in conflitto con UPDATE 2)

Considerando il caso in cui gli utenti di Windows preferiscono lavorare su CRLFe gli utenti linux / mac preferiscono lavorare su LFfile di testo. Fornire la risposta dal punto di vista di un manutentore del repository :

Per me la strategia migliore (meno problemi da risolvere) è: mantenere tutti i file di testo con LFrepository git interno anche se si sta lavorando su un progetto solo per Windows. Quindi dai la libertà ai clienti di lavorare sullo stile di fine linea delle loro preferenze , a condizione che scelgano un core.autocrlfvalore di proprietà che rispetti la tua strategia (LF su repo) durante la gestione temporanea dei file per il commit.

La stadiazione è ciò che molte persone confondono quando provano a capire come funzionano le strategie newline . È essenziale capire i seguenti punti prima di scegliere il valore corretto per la core.autocrlfproprietà:

• Aggiungere un file di testo per il commit ( metterlo in scena ) è come copiare il file in un'altra posizione all'interno della .git/sottodirectory con le terminazioni di riga convertite (a seconda del core.autocrlfvalore sulla configurazione del client). Tutto questo è fatto localmente.
• l'impostazione core.autocrlfè come fornire una risposta alla domanda (esattamente la stessa domanda su tutti i sistemi operativi):
  • "Dovrebbe git-client a. Convertire LF-in-CRLF durante il check-out (estrarre) le modifiche al repo dal telecomando o b. Convertire CRLF-in-LF quando si aggiunge un file per commit? " E le possibili risposte (valori) siamo:
  • false:" non fare nessuna delle precedenti ",
  • input:" fai solo b "
  • true: " fai a e eb "
  • notare che NON esiste " fare solo un "

per fortuna

• I valori predefiniti del client git (windows core.autocrlf: true:, linux / mac:) core.autocrlf: falsesaranno compatibili con la strategia repository solo LF .
  Significato : i client Windows verranno automaticamente convertiti in CRLF durante il check-out del repository e convertiti in LF durante l'aggiunta per il commit. E i client Linux per impostazione predefinita non eseguono alcuna conversione. Ciò teoricamente mantiene il tuo repo solo se disponibile.

Purtroppo:

• Potrebbero esserci client GUI che non rispettano il core.autocrlfvalore git
• Potrebbero esserci persone che non usano un valore per rispettare la tua strategia di lf-repo. Ad esempio, usano core.autocrlf=falsee aggiungono un file con CRLF per il commit.

Per rilevare file di testo non lf ASAP commessi dai client di cui sopra, è possibile seguire ciò che è descritto su --- update 2 ---: ( git grep -I --files-with-matches --perl-regexp '\r' HEAD, su un client compilato usando: --with-libpcreflag)

E qui è il fermo: . Come conservatore del repository, conservo un git.autocrlf=inputmodo per poter correggere eventuali file erroneamente impegnati semplicemente aggiungendoli di nuovo per il commit. E fornisco un testo di commit: "Correzione di file con commit errato".

Per quanto .gitattributesè stato appreso. Non ci conto, perché ci sono più clienti che non lo capiscono. Lo uso solo per fornire suggerimenti per file di testo e binari e forse contrassegnare alcuni file eccezionali che dovrebbero ovunque mantenere le stesse terminazioni di riga:

*.java          text !eol # Don't do auto-detection. Treat as text (don't set any eol rule. use client's)
*.jpg           -text     # Don't do auto-detection. Treat as binary
*.sh            text eol=lf # Don't do auto-detection. Treat as text. Checkout and add with eol=lf
*.bat           text eol=crlf # Treat as text. Checkout and add with eol=crlf

Domanda: Ma perché siamo tutti interessati alla strategia di gestione di newline?

Risposta: Per evitare un commit di modifica a una sola lettera, appare come un cambiamento di 5000 righe , solo perché il client che ha eseguito la modifica ha convertito automaticamente il file completo da crlf a lf (o viceversa) prima di aggiungerlo per il commit. Questo può essere piuttosto doloroso quando c'è una risoluzione del conflitto . O potrebbe in alcuni casi essere la causa di conflitti irragionevoli.

--- AGGIORNAMENTO 2 ---

Le impostazioni predefinite del client git funzioneranno nella maggior parte dei casi. Anche se hai solo client Windows, solo client Linux o entrambi. Questi sono:

• windows: core.autocrlf=true significa convertire le linee in CRLF al momento del pagamento e convertire le linee in LF quando si aggiungono file.
• linux: core.autocrlf=input significa non convertire le linee al momento del checkout (non è necessario poiché i file devono essere impegnati con LF) e convertire le linee in LF (se necessario) quando si aggiungono file. ( - update3 - : sembra che questo sia falsepredefinito, ma di nuovo va bene)

La proprietà può essere impostata in diversi ambiti. Suggerirei di impostare esplicitamente l' --globalambito, per evitare alcuni problemi IDE descritti alla fine.

git config core.autocrlf
git config --global core.autocrlf
git config --system core.autocrlf
git config --local core.autocrlf
git config --show-origin core.autocrlf

Inoltre scoraggerei fortemente l' uso su Windows git config --global core.autocrlf false (nel caso in cui tu abbia client solo Windows) in contrasto con quanto proposto per git documentazione . L'impostazione su false impegna i file con CRLF nel repository. Ma non c'è davvero alcun motivo. Non si sa mai se sarà necessario condividere il progetto con utenti Linux. Inoltre è un ulteriore passaggio per ogni client che si unisce al progetto invece di utilizzare i valori predefiniti.

Ora per alcuni casi speciali di file (ad es. *.bat *.sh) Che si desidera vengano estratti con LF o con CRLF è possibile utilizzare.gitattributes

Riassumendo per me la migliore pratica è:

• Assicurati che ogni file non binario sia sottoposto a commit con LF su git repo (comportamento predefinito).
• Utilizzare questo comando per assicurarsi che nessun file sia sottoposto a commit con CRLF: git grep -I --files-with-matches --perl-regexp '\r' HEAD( Nota: sui client Windows funziona solo attraverso git-bashe sui client Linux solo se compilato usando --with-libpcrein ./configure).
• Se trovi tali file eseguendo il comando sopra, correggili. Ciò implica (almeno su Linux):
  • set core.autocrlf=input( --- aggiorna 3 - )
  • cambia il file
  • annulla la modifica (il file viene ancora mostrato come modificato)
  • commettilo
• Usa solo il minimo indispensabile .gitattributes
• Indicare agli utenti di impostare i core.autocrlfvalori predefiniti sopra descritti.
• Non contare al 100% sulla presenza di .gitattributes. I client git di IDE possono ignorarli o trattarli in modo diverso.

Come detto alcune cose possono essere aggiunte negli attributi git:

# Always checkout with LF
*.sh            text eol=lf
# Always checkout with CRLF
*.bat           text eol=crlf

Penso che alcune altre opzioni sicure .gitattributesinvece di utilizzare il rilevamento automatico per i file binari:

• -text(ad es. per *.zipo *.jpgfile: non saranno trattati come testo. Pertanto non verrà tentata alcuna conversione di fine riga. La diffusione potrebbe essere possibile tramite i programmi di conversione)
• text !eol(ad esempio per *.java, *.html:.. trattata come testo, ma la preferenza stile EOL non è impostata in modo viene utilizzata la configurazione del client)
• -text -diff -merge(ad es. per *.hugefile: non trattato come testo. Nessuna differenza / unione possibile)

--- AGGIORNAMENTO PRECEDENTE ---

Un esempio doloroso di un client che commetterà i file in modo errato:

netbeans 8.2 (su Windows), commetterà erroneamente tutti i file di testo con CRLF, a meno che non sia stato impostato esplicitamente core.autocrlfcome globale . Ciò è in contraddizione con il comportamento standard del client git e causa molti problemi in seguito, durante l'aggiornamento / l'unione. Questo è ciò che rende alcuni file diversi (anche se non lo sono) anche quando si ripristina .
Lo stesso comportamento nei netbeans si verifica anche se hai aggiunto correttamente .gitattributesal tuo progetto.

L'uso del comando seguente dopo un commit ti aiuterà almeno a rilevare in anticipo se il tuo repository git presenta problemi di fine riga: git grep -I --files-with-matches --perl-regexp '\r' HEAD

Ho trascorso ore a trovare il miglior uso possibile .gitattributes, per realizzare finalmente, che non posso contare su di esso.
Sfortunatamente, finché esistono editor basati su JGit (che non possono gestire .gitattributescorrettamente), la soluzione sicura è forzare LF ovunque, anche a livello di editor.

Utilizzare i seguenti anti-CRLFdisinfettanti.

• client windows / linux: core.autocrlf=input

• impegnato .gitattributes: * text=auto eol=lf

• commit .editorconfig( http://editorconfig.org/ ) che è una specie di formato standardizzato, combinato con plug-in editor:

  • https://github.com/editorconfig/
  • https://github.com/welovecoding/editorconfig-netbeans/

Questa è solo una soluzione alternativa :

In casi normali, utilizzare le soluzioni fornite con git. Questi funzionano alla grande nella maggior parte dei casi. Forza su LF se condividi lo sviluppo su sistemi basati su Windows e Unix impostando .gitattributes .

Nel mio caso c'erano> 10 programmatori che sviluppavano un progetto in Windows. Questo progetto è stato verificato con CRLF e non c'era alcuna possibilità di forzare a LF.

Alcune impostazioni sono state scritte internamente sulla mia macchina senza alcuna influenza sul formato LF; quindi alcuni file sono stati cambiati globalmente in LF ad ogni piccola modifica di file.

La mia soluzione:

Macchine Windows: lascia tutto così com'è. Non ti preoccupare di nulla, dato che sei uno sviluppatore 'lupo solitario' di Windows predefinito e devi gestire in questo modo: "Non esiste un altro sistema in tutto il mondo, vero?"

Unix-Macchine

1. Aggiungi le seguenti righe alla [alias]sezione di una configurazione . Questo comando elenca tutti i file modificati (ovvero modificati / nuovi):

   lc = "!f() { git status --porcelain \
                | egrep -r \"^(\?| ).\*\\(.[a-zA-Z])*\" \
                | cut -c 4- ; }; f "

2. Converti tutti i file modificati nel formato dos:

   unix2dos $(git lc)

3. Opzionalmente ...

   1. Crea un hook git per questa azione per automatizzare questo processo

   2. Usa params e includilo e modifica la grepfunzione in modo che corrisponda solo a nomi di file particolari, ad esempio:

      ... | egrep -r "^(\?| ).*\.(txt|conf)" | ...

   3. Sentiti libero di renderlo ancora più conveniente utilizzando un collegamento aggiuntivo:

      c2dos = "!f() { unix2dos $(git lc) ; }; f "

      ... e spara le cose convertite digitando

      git c2dos