git sostituisce LF con CRLF

840

Esecuzione di git su un computer Windows XP, usando bash. Ho esportato il mio progetto da SVN e quindi clonato un repository nudo.

Ho quindi incollato l'esportazione nella directory dei repository nudi e ho fatto un:

git add -A

Ho quindi ricevuto un elenco di messaggi che dicevano:

LF sarà sostituito da CRLF

Quali sono le conseguenze di questa conversione? Questa è una soluzione .NET in Visual Studio.

git

— mrblah
fonte

14

@apphacker perché standardizzare le terminazioni di linea è meno fastidioso che doverle cambiare da soli quando si diffondono due file. (E, naturalmente, se non sei d'accordo, puoi disattivare la funzione core.autocrlf).

— RJFalconer,

2

perché le terminazioni delle linee sarebbero diverse se non si toccasse l'intera linea

— Bjorn

3

Tocco spesso molte righe, perché sto sperimentando idee diverse, aggiungendo istruzioni trace per vedere come funzionano, ecc. Quindi potrei voler solo commettere una modifica a due o tre righe e avere git completamente ignorare le altre perché li avevo rimessi nel modo in cui li avevo trovati (o almeno così pensavo).

— MatrixFrog,

5

@MatrixFrog: il tuo editor sembra rotto, incapace di rilevare automaticamente le terminazioni di linea. Cos'è questo? Lavoro a progetti ibridi che devono avere alcuni file LF e altri file CRLF nello stesso repository. Non è un problema per nessun editor moderno. Avere il controllo della versione (o il trasferimento di file) in disordine con le terminazioni di riga per aggirare le limitazioni dell'editor è l'idea peggiore di sempre - ovvio dalla mera lunghezza delle spiegazioni di seguito.

— MarcH,

4

L'unico editor moderno che conosco che fa la cosa sbagliata è Visual Studio. Visual Studio aprirà felicemente un file con terminazioni di linea LF. Se quindi inserisci nuove righe, inserirà CRLF e salverà le terminazioni di linee miste. Microsoft rifiuta di risolvere questo problema, il che è un grosso difetto per un IDE altrimenti abbastanza buono: - (

— Jon Watte,

957

Questi messaggi sono dovuti a un valore predefinito errato di core.autocrlfsu Windows.

Il concetto di autocrlfè di gestire le conversioni dei finali di linea in modo trasparente. E lo fa!

Cattive notizie : il valore deve essere configurato manualmente.
Buone notizie : dovrebbe essere eseguito UNA SOLA volta per installazione di git (è possibile anche l'impostazione del progetto).

Come autocrlffunziona :

core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:

        repo                     repo                     repo
      ^      V                 ^      V                 ^      V
     /        \               /        \               /        \
crlf->lf    lf->crlf     crlf->lf       \             /          \      
   /            \           /            \           /            \

Qui crlf= marker di fine riga in stile win, lf= unix-style (e mac osx).

(pre-osx crnon è interessato per nessuna delle tre opzioni sopra)

Quando viene visualizzato questo avviso (in Windows)

    - autocrlf= truese hai lfuno stile unix in uno dei tuoi file (= RARAMENTE),
    - autocrlf= inputse hai crlfuno stile win in uno dei tuoi file (= quasi SEMPRE),
    - autocrlf= false- MAI!

Cosa significa questo avviso

L'avviso " LF sarà sostituito da CRLF " dice che tu (avendo autocrlf= true) perderai il tuo LF in stile unix dopo il ciclo di commit-checkout (sarà sostituito da CRLF in stile Windows). Git non si aspetta che tu usi LF in stile unix sotto Windows.

L'avviso " CRLF sarà sostituito da LF " dice che tu (avendo autocrlf= input) perderai il tuo CRLF in stile Windows dopo un ciclo di commit-checkout (sarà sostituito da LF in stile unix). Non usare inputsotto Windows.

Ancora un altro modo per mostrare come autocrlffunziona

1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x

dove x è CRLF (stile windows) o LF (stile unix) e le frecce indicano

file to commit -> repository -> checked out file

Come risolvere

Il valore predefinito per core.autocrlfè selezionato durante l'installazione di git e memorizzato in gitconfig ( %ProgramFiles(x86)%\git\etc\gitconfig) a livello di sistema. Inoltre ci sono (a cascata nel seguente ordine):

   - "global" (per utente) gitconfig situato in ~/.gitconfig, ancora un altro
   - "global" (per utente) gitconfig at $XDG_CONFIG_HOME/git/configoppure $HOME/.config/git/confige
   - "local" (per-repo) gitconfig at .git/confignella directory di lavoro.

Quindi, scrivere git config core.autocrlfnella directory di lavoro per verificare il valore attualmente utilizzato e

   - aggiungere autocrlf=falsea gitconfig # soluzione per sistema di sistema
   - git config --global core.autocrlf false        # soluzione per utente
   - git config --local core.autocrlf false            # soluzione per progetto

Avvertenze
: le git configimpostazioni possono essere ignorate dalle gitattributesimpostazioni.
- la crlf -> lfconversione avviene solo quando si aggiungono nuovi file, i crlffile già esistenti nel repository non sono interessati.

Morale (per Windows):
    - use core.autocrlf= truese si prevede di utilizzare questo progetto anche in Unix (e non si desidera configurare il proprio editor / IDE per utilizzare le terminazioni di linea unix),
    - use core.autocrlf= falsese si prevede di utilizzare questo progetto solo in Windows ( o hai configurato il tuo editor / IDE per utilizzare le terminazioni di linea unix),
    - non usare maicore.autocrlf = a inputmeno che tu non abbia una buona ragione per ( ad esempio se stai usando utility unix sotto Windows o se riscontri problemi di makefile),

PS Cosa scegliere quando si installa git per Windows?
Se non utilizzerai nessuno dei tuoi progetti in Unix, non concordare con la prima opzione predefinita. Scegli il terzo ( Acquista così com'è, esegui il commit così com'è ). Non vedrai questo messaggio. Mai.

PPS La mia preferenza personale è la configurazione dell'editor / IDE per utilizzare i finali in stile Unix e l'impostazione core.autocrlfsu false.

— Antony Hatchkins
fonte

28

Per la quantità di tempo che ho speso per arrivare così lontano, speravo in un core.crlf = rackoff ;-)

— PandaWood

10

Ho ristrutturato il contenuto, forse sarà più facile da leggere in questo modo

— Antony Hatchkins,

7

scusate, spero che il mio commento non sia stato preso come critica alla vostra risposta. Per "arrivare così lontano" intendo, prima di trovare questa risposta.

— PandaWood,

10

Questo è così confuso. Ho LF impostato nel mio editor. Tutto il codice repository utilizza LF. global autocrlf è impostato su false e il core gitconfig nella mia home directory è impostato su false. Ma ricevo ancora il messaggio LF che viene sostituito con CRLF

— Isimmons il

17

Se hai configurato il tuo editor per utilizzare i finali in stile Unix, perché non impostare core.autocrlfl'input? Da quello che ho raccolto dalla tua risposta, impostandolo su input si assicura che il repository e la directory di lavoro abbiano sempre terminazioni di riga in stile unix. Perché non lo vorresti mai in Windows?

— Hubro,

764

Git ha tre modalità di come tratta le terminazioni di linea:

$ git config core.autocrlf
# that command will print "true" or "false" or "input"

È possibile impostare la modalità da utilizzare aggiungendo un parametro aggiuntivo trueo falsealla riga di comando sopra.

Se core.autocrlfimpostato su true, ciò significa che ogni volta che aggiungi un file al repository git che git ritiene sia un file di testo, trasformerà tutte le terminazioni di riga CRLF in LF prima di memorizzarlo nel commit. Ogni volta che git checkoutqualcosa, tutti i file di testo avranno automaticamente le loro terminazioni di linea LF convertite in terminazioni CRLF. Ciò consente lo sviluppo di un progetto su piattaforme che utilizzano diversi stili di fine linea senza che i commit siano molto rumorosi perché ogni editor modifica lo stile di fine linea poiché lo stile di fine linea è sempre costantemente LF.

L'effetto collaterale di questa comoda conversione, e questo è l'avvertimento che stai vedendo, è che se un file di testo che hai creato aveva originariamente terminazioni LF invece di CRLF, verrà archiviato con LF come al solito, ma se selezionato più tardi avrà terminazioni CRLF. Per i normali file di testo questo di solito va bene. L'avvertimento è un "per tua informazione" in questo caso, ma nel caso in cui git valuti erroneamente un file binario come file di testo, è un avvertimento importante perché git danneggerebbe il tuo file binario.

Se core.autocrlfimpostato su false, non viene mai eseguita alcuna conversione di fine riga, quindi i file di testo vengono registrati così come sono. Questo di solito funziona bene, a condizione che tutti i tuoi sviluppatori siano su Linux o su Windows. Ma nella mia esperienza tendo ancora a ottenere file di testo con terminazioni di linee miste che finiscono per causare problemi.

La mia preferenza personale è lasciare l'impostazione ON, come sviluppatore di Windows.

Vedere http://kernel.org/pub/software/scm/git/docs/git-config.html per informazioni aggiornate che includono il valore "input".

— Andrew Arnott
fonte

116

Come detto qui ( stackoverflow.com/questions/1249932/… ), sarei in disaccordo con rispetto e lascerei l'impostazione su OFF (e uso Notepad ++ o qualsiasi altro editor in grado di gestire - e lasciare così com'è - qualunque carattere di fine riga trova)

— VonC,

23

Mi piace questa risposta e preferisco lasciare autocrlf impostato su true. In alternativa, c'è un modo per eliminare automaticamente i messaggi di avviso?

— Krisc,

12

Sarebbe bello aumentare questa risposta ben scritta con un confronto con le core.eolimpostazioni, forse in accordo con la .gitattributesconfigurazione. Ho cercato di capire le differenze e le sovrapposizioni attraverso la sperimentazione, ed è molto confuso.

— seh

5

Per una soluzione più permanente, modifica il tuo .gitconfig in: [core] autocrlf = false

— RBZ

9

C'è un modo semplice per eliminare semplicemente l'avvertimento? Voglio che sia vero e so che l'ho impostato su vero. Non ho bisogno di vedere tutti gli avvisi in ogni momento ... Va tutto bene, davvero ...: p

— UmaN

160

Se hai già estratto il codice, i file sono già indicizzati. Dopo aver modificato le impostazioni di Git, dire eseguendo:

git config --global core.autocrlf input

dovresti aggiornare gli indici con

git rm --cached -r .

e riscrivere indice git con

git reset --hard

https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings

Nota: questo rimuoverà le modifiche locali, considera di metterle da parte prima di procedere.

— user2630328
fonte

23

Grazie per un modo semplice, multipiattaforma e chiaro per FISSARLO, piuttosto che un'enorme discussione sul significato della configurazione.

— Eris,

2

se git reset --hard è possibile che la mia modifica locale venga persa? seguo solo tutti i commenti sopra citati

— Freddy Sidauruk,

5

Sì, le modifiche locali andranno perse. Il parametro --hard reimposta l'indice e l'albero di lavoro in modo da eliminare eventuali modifiche ai file tracciati. git-scm.com/docs/git-reset

— Jacques

2

Cosa significa git rm --cached -r .? Perché git reset --hardnon è abbastanza?

— gavenkoa,

2

@gavenkoa @max È necessario l'opzione git rm --cached -r .Se lo fai git reset --harddopo aver modificato l' core.autocrlfimpostazione, non convertirà nuovamente le terminazioni di linea. Devi pulire l'indice git.

— Wisbucky,

80

git config core.autocrlf false

— Arun
fonte

6

assicurati di eseguire questo all'interno del repository root

— Hammad Khan,

23

Non capisco come possa essere utile. La metà delle persone richiede che autocrlf sia vero perché funzioni, l'altra metà deve essere false / input. Quindi, cosa dovrebbero lanciare casualmente queste risposte una tantum sulla loro console fino a quando qualcosa non si attacca e una sorta di "funziona"? Questo non è produttivo.

— Zoran Pavlovic,

Viene visualizzato l'errore "fatale: non in una directory git". Ho provato a fare cd su C: \ Programmi \ Git e C: \ Programmi \ Git \ bin

— pixelwiz,

2

@mbb impostazione autcrlfper puntare falseil problema a tutti gli utenti del progetto.

— jpaugh,

5

@pixelwiz: questo comando imposta la proprietà solo per il progetto (quindi è necessario trovarsi in un repository git per eseguirlo). Se vuoi impostarlo a livello globale, usa git config --global core.autocrlf falseinvece.

— Michaël Polla,

49

Sia unix2dos che dos2unix è disponibile in Windows con gitbash. È possibile utilizzare il comando seguente per eseguire la conversione UNIX (LF) -> DOS (CRLF). Quindi, non riceverai l'avviso.

unix2dos filename

o

dos2unix -D filename

Ma non eseguire questo comando su alcun file CRLF esistente, quindi ogni riga verrà visualizzata una riga vuota.

dos2unix -D filenamenon funzionerà con tutti i sistemi operativi. Controlla questo link per la compatibilità.

Se per qualche motivo è necessario forzare il comando, utilizzare --force. Se si dice non valido, utilizzare -f.

— Rifat
fonte

8

Che cosa fa?

— Salman von Abbas,

1

Ecco cosa dice l'opzione di aiuto: `--u2d, -D esegue UNIX -> conversione DOS`

— Larry Battle

1

@Rifat Sono confuso. Il tuo commento dice che dos2unix -Dconvertirà le terminazioni di linea di Windows in terminazioni di linea di Linux. Non è lo stesso della conversione DOS (CRLF) -> UNIX (LF). Tuttavia dos2unix -hafferma che -Deseguirà la conversione UNIX (LF) -> DOS (CRLF). dos2unix Ulteriori informazioni: gopherproxy.meulie.net/sdf.org/0/users/pmyshkin/dos2unix

— Larry Battle

1

@LarryBattle Sì, hai ragione su -D. In realtà, ho pubblicato la risposta quando ero un utente di Windows. E ho fatto il commento più di un anno dopo quando sono un utente mac: D BTW, Grazie per il chiarimento.

— Rifat,

1

Questo ha funzionato per me. Sto usando Cygwin, che non sembra supportare l'opzione -D - ma c'è il comando "unix2dos", che fa la stessa cosa. Vorrei sapere cosa ha causato il problema, però: ho core.autocrlf = false ed è un repository solo per Windows.

— Richard Beier,

28

Penso che la risposta di @ Basiloungas sia vicina ma obsoleta (almeno su Mac).

Apri il file ~ / .gitconfig e imposta safecrlfsu false

[core]
       autocrlf = input
       safecrlf = false

Che * lo farà ignorare il carattere finale della linea apparentemente (ha funzionato per me, comunque).

— Yevgeny Simkin
fonte

1

Dovrebbe essere safecrlf(con una 'f')

— alpipego il

22

Un articolo di GitHub sulle terminazioni di riga viene comunemente menzionato quando si parla di questo argomento.

La mia esperienza personale con l'uso dell'impostazione di core.autocrlfconfigurazione spesso consigliata è stata molto mista.

Sto usando Windows con Cygwin, occupandomi di progetti Windows e UNIX in momenti diversi. Anche i miei progetti Windows a volte usano bashscript di shell, che richiedono terminazioni di linea UNIX (LF).

Utilizzando l' core.autocrlfimpostazione consigliata di GitHub per Windows, se controllo un progetto UNIX (che funziona perfettamente su Cygwin - o forse sto contribuendo a un progetto che utilizzo sul mio server Linux), i file di testo vengono estratti con Windows (CRLF ) terminazioni di riga, creando problemi.

Fondamentalmente, per un ambiente misto come il mio, impostare il globale core.autocrlfsu una qualsiasi delle opzioni non funzionerà bene in alcuni casi. Questa opzione potrebbe essere impostata su una config git locale (repository), ma anche quella non sarebbe abbastanza buona per un progetto che contiene elementi relativi sia a Windows che a UNIX (ad esempio ho un progetto Windows con alcuni bashscript di utilità).

La scelta migliore che ho trovato è quella di creare file .gitattributes per repository . L' articolo di GitHub lo menziona.
Esempio da quell'articolo:

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

In uno dei repository del mio progetto:

* text=auto

*.txt         text eol=lf
*.xml         text eol=lf
*.json        text eol=lf
*.properties  text eol=lf
*.conf        text eol=lf

*.awk  text eol=lf
*.sed  text eol=lf
*.sh   text eol=lf

*.png  binary
*.jpg  binary

*.p12  binary

È un po 'più di cose da configurare, ma fallo una volta per progetto e qualsiasi collaboratore su qualsiasi sistema operativo non dovrebbe avere problemi con le terminazioni di linea quando lavora con questo progetto.

— Gene Pavlovsky
fonte

In questo momento, provando a gestire un repository con script Cygwin tra altri file di testo di base. Come gestiresti i file senza estensione (es. "Fstab", "sshd_config")? L'articolo collegato non copre questo scenario.

— Mike Loux,

1

@MikeLoux Prova questo metodo: stackoverflow.com/a/44806034/4377192

— Gene Pavlovsky,

Ho scoperto che ha text=false eol=falsefunzionato in qualche modo in modo simile a binary. Suona bene? Potrebbe essere utile indicare "So che si tratta di file di testo, ma non voglio che siano normalizzati"

— joeytwiddle,

19

In vim aprire il file (ad es . :e YOURFILEENTER:), quindi

:set noendofline binary
:wq

— Roman Rhrn Nesterov
fonte

2

La semplice modifica con vimlascerebbe intatta tutta la fine della riga.

— Occhio

Ho riscontrato questo problema con alcuni file Cocoapods. Quanto sopra risolto la maggior parte di loro; per il resto, s / {control-v} {control-m} // ha fatto il trucco. I due codici di controllo insieme fanno la ^ M che quelli di noi su OS X vedono spesso nei file di Windows.

— janineanne,

16

Ho avuto anche questo problema.

SVN non esegue alcuna conversione di fine riga, pertanto i file vengono sottoposti a commit con i finali di riga CRLF intatti. Se poi usi git-svn per mettere il progetto in git, le terminazioni CRLF persistono nel repository git, che non è lo stato in cui git si aspetta di trovarsi - il default è avere solo terminazioni di linea unix / linux (LF) controllato.

Quando poi verifichi i file su Windows, la conversione di autocrlf lascia intatti i file (poiché hanno già i finali corretti per la piattaforma corrente), tuttavia il processo che decide se c'è una differenza con i file archiviati esegue la conversione inversa prima del confronto, con il risultato di confrontare ciò che pensa sia un LF nel file estratto con un CRLF imprevisto nel repository.

Per quanto posso vedere le tue scelte sono:

Reimportare il codice in un nuovo repository git senza usare git-svn, questo significa che i finali di riga vengono convertiti nel commit git iniziale --all
Impostare autocrlf su false e ignorare il fatto che le terminazioni di linea non sono nello stile preferito di git
Controlla i tuoi file con autocrlf disattivato, correggi tutti i finali di riga, controlla di nuovo tutto e riaccendilo.
Riscrivi la cronologia del tuo repository in modo che il commit originale non contenga più il CRLF che git non si aspettava. (Si applicano le solite avvertenze sulla riscrittura della storia)

Nota a piè di pagina: se si sceglie l'opzione n. 2, la mia esperienza è che alcuni degli strumenti ausiliari (rebase, patch ecc.) Non gestiscono i file CRLF e finirai prima o poi con i file con un mix di CRLF e LF (linea incoerente terminazioni). Non conosco alcun modo per ottenere il meglio da entrambi.

— Tim Abell
fonte

2

Penso che ci sia una quarta opzione da aggiungere al tuo elenco, supponendo che uno possa permettersi di riscrivere la cronologia: puoi prendere un repository git che hai creato inizialmente con git-svn e riscrivere la sua cronologia per non avere più feed di linea CRLF. Ciò ti darebbe avanzamenti di riga normalizzati che si estendono all'indietro attraverso l'intera cronologia svn. User keo presenta una soluzione su stackoverflow.com/a/1060828/64257 .

— Chris

Informazioni sulla nota a piè di pagina: rebasenon ha problemi con CRLF. L'unico problema che conosco è che lo strumento standard git merge inserirà i suoi marker di conflitto ("<<<<<<", ">>>>>>" ecc.) Solo con LF, quindi un file con marker di conflitto hanno terminazioni di riga miste. Tuttavia, una volta rimossi i marcatori, tutto va bene.

— sleske il

È possibile che la gestione di Git sia cambiata negli ultimi 3 anni, questa è stata la mia esperienza diretta al momento, da allora non ho più avuto bisogno di rivedere questo particolare problema. YMMV.

— Tim Abell,

1

@sleske a partire da git 2.8, i marker di unione non introdurranno più la fine della linea mista. Vedere stackoverflow.com/a/35474954/6309

— VonC

@VonC: è fantastico. Buono a sapersi per le volte in cui ho bisogno di lavorare su Windows.

— sleske,

12

Rimozione di quanto segue dal file ~ / .gitattributes

* text=auto

impedirà a git di controllare le terminazioni di riga in primo luogo.

— basiloungas
fonte

6

Non corretto. Quella riga, se presente, sovrascriverà la configurazione di core.autocrlf. Se è impostato su "true", allora no, rimuovendo quella linea non si impedisce a git di controllare i finali di linea.

— Arafangion,

1

Tuttavia, se core.autocrlf è impostato su false, se questo non viene rimosso impostando autocrlf su false non sarà di grande aiuto, quindi questo mi ha aiutato (ma da solo non è abbastanza).

— Matty,

2

Voto questo !! Mentre la parte "impedirà a git di controllare" non è tecnicamente corretta, questa è l'UNICA risposta che menziona in modo specifico l' text=impostazione .gitattributes(che, se presente, sarà un blocco). Quindi le altre risposte sono incomplete. Stavo andando fuori di testa cercando di capire perché i miei file continuavano a essere visualizzati come "modificati", non importa quante volte ho cambiato il mio autocrlfe le safecrlfimpostazioni e verificato e cancellato la cache git e hard reset.

— jdunk,

10

Dovrebbe leggere:

avvertimento: ( Se lo controlli / o cloni in un'altra cartella con il tuo core.autocrlf attualetrue ,) LF sarà sostituito da CRLF

Il file avrà le sue terminazioni di riga originali nella directory di lavoro ( corrente ).

Questa immagine dovrebbe spiegare cosa significa.

— Xiao Peng - ZenUML.com
fonte

Significa anche che ciò che viene inviato a Subversion (se lo fai) avrà la conversione.

— jpaugh,

10

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/

echo "* -crlf" > .gitattributes

Farlo su un commit separato o git potrebbe comunque vedere interi file modificati quando si apporta una singola modifica (a seconda se è stata modificata l'opzione autocrlf)

Questo funziona davvero. Git rispetterà le terminazioni di linea nei progetti di fine linea mista e non ti avvertirà di loro.

— Nastri di Michael
fonte

2

Questo è particolarmente utile quando vuoi convertire tra CRLF e LF, ma hai alcuni file .sh che devono rimanere intatti. Uso *.sh -crlftutto il tempo ...

— MartinTeeVarga,

9

Non so molto su Git su Windows, ma ...

Mi sembra che git stia convertendo il formato di ritorno in modo che corrisponda a quello della piattaforma in esecuzione (Windows). CRLF è il formato di ritorno predefinito in Windows, mentre LF è il formato di ritorno predefinito per la maggior parte degli altri sistemi operativi.

È probabile che il formato di ritorno verrà regolato correttamente quando il codice viene spostato su un altro sistema. Penso anche che git sia abbastanza intelligente da mantenere intatti i file binari piuttosto che cercare di convertire LF in CRLF, per esempio in JPEG.

In sintesi, probabilmente non dovrai preoccuparti troppo di questa conversione. Tuttavia, se vai ad archiviare il tuo progetto come tarball, gli altri programmatori apprezzerebbero probabilmente avere terminatori di linea LF piuttosto che CRLF. A seconda di quanto ti interessa (e a seconda che non usi Notepad), potresti voler impostare git per usare i rendimenti LF se puoi :)

Appendice: CR è il codice ASCII 13, LF è il codice ASCII 10. Pertanto, CRLF è due byte, mentre LF è uno.

— Joey Adams
fonte

5

Poiché nessuno sembra averlo detto, CR sta per "Carriage Return" e LF sta per "Line Feed". Come seconda nota, molti editor di Windows cambieranno silenziosamente un file di testo con il carattere LF che indica una nuova riga per essere invece la coppia di caratteri CRLF. L'utente dell'editor non verrà nemmeno avvisato, ma Git vedrà il cambiamento.

— user2548343

7

Assicurati di aver installato l'ultimo git.
Ho fatto come sopra git config core.autocrlf false, quando usato git (versione 2.7.1), ma non ha funzionato.
Quindi funziona ora quando aggiorna git (dalla 2.7.1 alla 2.20.1).

— ivi tan
fonte

Penso che volevi dire che avevi git 2.17.1. Avevo lo stesso problema e ho fatto l'aggiornamento e anche questo ha risolto il problema. Sono contento di aver visto la tua risposta!

— Phillip McMullen,

5

Apri il file in Notepad ++.
Vai a Modifica / Conversione EOL.
Fai clic sul formato Windows.
Salva il file.

— 1991tama1991
fonte

1

Prova anche a usare git config --global core.autocrlf falseper impedire a Git di impostare le terminazioni di linea Unixsu un commit. Seguire git config core.autocrlfper verificare che sia effettivamente impostato su false.

— Contango,

5

La domanda di OP è relativa a Windows e non ho potuto usare gli altri senza andare nella directory o persino eseguire il file in Notepad ++ poiché l'amministratore non ha funzionato .. Quindi ho dovuto seguire questa strada:

C:\Program Files (x86)\Git\etc>git config --global core.autocrlf false

— tiltedtimmy
fonte

3

Molti editor di testo ti consentono di passare a LF, vedi le istruzioni Atom di seguito. Semplice ed esplicito.

Clicca CRLFin basso a destra:

Seleziona LFnel menu a discesa in alto:

— JBallin
fonte

2

In un prompt della shell GNU / Linux, i comandi dos2unix e unix2dos consentono di convertire / formattare facilmente i file provenienti da MS Windows

— Ronan
fonte

2

CRLF potrebbe causare alcuni problemi durante l'utilizzo del "codice" in due diversi sistemi operativi (Linux e Windows). Il mio script Python è stato scritto nel contenitore docker di Linux e quindi è stato inviato tramite Windows git-bash. Mi ha dato l'avvertimento che LF sarà sostituito da CRLF. Non ci ho pensato molto, ma poi quando ho iniziato la sceneggiatura, ha detto /usr/bin/env: 'python\r': No such file or directory. Ora che \rper una ramificazione per te. Windows utilizza "CR" - ritorno a capo - sopra "\ n" come nuovo carattere di riga - \n\r. È qualcosa che potresti dover considerare.

— Kshitiz
fonte

0

La maggior parte degli strumenti di Windows accetta solo LF nei file di testo. Ad esempio è possibile controllare il comportamento di Visual Studio in un file denominato ".editorconfig" con il seguente contenuto di esempio (parte):

 indent_style = space
 indent_size = 2
 end_of_line = lf    <<====
 charset = utf-8

Solo il blocco note originale di Windows non funziona con LF ma ci sono alcuni semplici strumenti di editor disponibili!

Quindi dovresti usare LF anche nei file di testo in Windows. Questo è il mio messaggio, fortemente raccomandato! Non c'è motivo di usare CRLF in Windows!

(La stessa discussione sta usando \ in include percorsi in C / ++, è una cazzata, usa #include <pathTo / myheader.h> con barra !, È lo standard C / ++ e tutti i compilatori di Microsoft lo supportano).

Quindi l'impostazione corretta per git è

git config core.autocrlf false

Il mio messaggio: dimentica i vecchi programmi di pensiero come dos2unix e unix2dos. Chiarisci nel tuo team che LF è corretto da usare in Windows.

— Hartmut Schorrig
fonte