Windows git "avviso: LF sarà sostituito da CRLF", quella coda di avviso è all'indietro?

ENV:

• Windows 7
• msysgit

Wheng I git commit, dice:

warning: LF will be replaced by CRLF. 

Questa coda di avvertimento è arretrata?
Modifica il file in Windows, la fine della linea è CRLF, proprio come questa immagine:

E git lo cambia LFper impegnarsi in repo.
Quindi penso che l'avviso corretto sia:

warning: CRLF will be replaced by LF. 

avviso: LF sarà sostituito da CRLF.

A seconda dell'editor che si sta utilizzando, un file di testo con LF non dovrebbe essere salvato con CRLF: gli editor recenti possono conservare stile eol. Ma quell'impostazione di configurazione git insiste nel cambiare quelle ...

Assicurati semplicemente che (come ti consiglio qui ):

git config --global core.autocrlf false

In questo modo, eviti qualsiasi trasformazione automatica e puoi comunque specificarle tramite un .gitattributesfile e le core.eoldirettive .

windows git "LF sarà sostituito da CRLF"
Questa coda di avvertimento è arretrata?

No: sei su Windows e menziona la git configpagina di aiuto

Utilizzare questa impostazione se si desidera avere CRLFterminazioni di riga nella directory di lavoro anche se il repository non ha terminazioni di linea normalizzate.

Come descritto in " git sostituzione di LF con CRLF ", dovrebbe avvenire solo al checkout (non commit), con core.autocrlf=true.

       repo
    /        \ 
crlf->lf    lf->crlf 
 /              \    

Come accennato in Xiaopeng 's risposta , che l'avvertimento è la stessa:

avvertimento: (Se lo fai check out / o cloni in un'altra cartella con la tua core.autocrlfconfigurazione attuale ,) LF sarà sostituito da CRLF
Il file avrà le sue terminazioni di riga originali nella tua (corrente) directory di lavoro.

Come menzionato nel git-for-windows/gitnumero 1242 :

Sento ancora questo messaggio confuso, il messaggio potrebbe essere esteso per includere una migliore spiegazione del problema, ad esempio: "LF verrà sostituito da CRLF file.jsondopo aver rimosso il file e averlo verificato di nuovo".

Nota: Git 2.19 (settembre 2018), quando si utilizza core.autocrlf, l'avvertimento "LF sarà sostituito da CRLF" è ora soppresso .

Come giustamente commenta quaylar , se c'è una conversione su commit, lo èLF solo.

Quell'avviso specifico " LF will be replaced by CRLF" proviene da convert.c # check_safe_crlf () :

if (checksafe == SAFE_CRLF_WARN)
  warning("LF will be replaced by CRLF in %s.
           The file will have its original line endings 
           in your working directory.", path);
else /* i.e. SAFE_CRLF_FAIL */
  die("LF would be replaced by CRLF in %s", path);

Viene chiamato da convert.c#crlf_to_git(), stesso chiamato da convert.c#convert_to_git(), stesso chiamato daconvert.c#renormalize_buffer() .

E quell'ultimo renormalize_buffer()è chiamato solo damerge-recursive.c#blob_unchanged() .

Quindi sospetto che questa conversione avvenga git commitsolo se detto commit fa parte di un processo di unione.

Nota: con Git 2.17 (Q2 2018), una pulizia del codice aggiunge alcune spiegazioni.

Vedi commit 8462ff4 (13 gennaio 2018) di Torsten Bögershausen ( tboegi) .
^{(Unito da Junio ​​C Hamano - gitster- in commit 9bc89b1 , 13 feb 2018)}

convert_to_git (): safe_crlf / checksafe diventa int conv_flags

Durante la chiamata convert_to_git(), il checksafeparametro ha definito cosa dovrebbe accadere se la conversione EOL ( CRLF --> LF --> CRLF) non ritorna in modo pulito.
Inoltre, ha anche definito se i finali di linea devono essere rinormalizzati ( CRLF --> LF) o mantenuti come sono.

checksafe era un safe_crlfenum con questi valori:

SAFE_CRLF_FALSE:       do nothing in case of EOL roundtrip errors
SAFE_CRLF_FAIL:        die in case of EOL roundtrip errors
SAFE_CRLF_WARN:        print a warning in case of EOL roundtrip errors
SAFE_CRLF_RENORMALIZE: change CRLF to LF
SAFE_CRLF_KEEP_CRLF:   keep all line endings as they are

Si noti che una regressione introdotta in 8462ff4 (" convert_to_git(): safe_crlf/checksafediventa int conv_flags", 13/01/2018, Git 2.17.0) nel ciclo Git 2.17 ha provocato autocrlfriscritture per produrre un messaggio di avviso nonostante l'impostazionesafecrlf=false .

Vedi commit 6cb0912 (04 giu 2018) di Anthony Sottile ( asottile) .
^{(Unito da Junio ​​C Hamano - gitster- in commit 8063ff9 , 28 giu 2018)}

SÌ l'avvertimento è al contrario.

E in effetti non dovrebbe nemmeno essere un avvertimento in primo luogo. Perché tutto questo avvertimento dice (ma sfortunatamente all'indietro) è che i caratteri CRLF nel tuo file con terminazioni di riga di Windows verranno sostituiti con LF in commit. Ciò significa che è normalizzato con le stesse terminazioni di linea utilizzate da * nix e MacOS.

Non sta succedendo niente di strano, questo è esattamente il comportamento che vorresti normalmente.

Questo avviso nella sua forma attuale è una delle due cose:

1. Un bug sfortunato combinato con un messaggio di avvertimento troppo cauto, o
2. Una trama molto intelligente per farti pensare davvero attraverso ...

;)

- Aggiornamento del 9 luglio ---

Rimosso "È corretto e preciso" come commentato da @mgiuca

======

NO . NON sta parlando dei tuoi file attualmente con CRLF. Si tratta invece di file conLF .

Dovrebbe leggere:

avvertimento: ( Se lo fai check out / o cloni in un'altra cartella con la tua attuale configurazione core.autocrlf ,) 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.

Tutto questo presuppone core.autocrlf=true

Errore originale:

avviso: LF verrà sostituito da CRLF
Il file avrà i suoi finali di riga originali nella directory di lavoro.

Cosa dovrebbe leggere l'errore:

avviso: LF verrà sostituito da CRLF nella directory di lavoro
Il file avrà le sue terminazioni di linea LF originali nel repository git

Spiegazione qui :

L'effetto collaterale di questa comoda conversione, e questo è ciò che riguarda l'avvertimento che stai vedendo, è che se un file di testo che hai creato originariamente aveva terminazioni LF invece di CRLF, verrà archiviato con LF come al solito, ma quando è 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.

Fondamentalmente, un file locale che in precedenza era LF ora avrà CRLF localmente

git config --global core.autocrlf false funziona bene per le impostazioni globali.

Ma se si utilizza Visual Studio, potrebbe essere necessario modificare anche .gitattributesper alcuni tipi di progetti ( ad esempio l'applicazione della libreria di classi c # ):

• rimuovere la linea * text=auto

Dopo aver impostato core.autocrlf=truestavo ottenendo "LF sarà sostituito da CRLF" (nota non "CRLF sarà sostituito da LF") quando stavo git adding (o forse era acceso git commit?) I file modificati in Windows su un repository (che utilizza LF) che è stato verificato prima di impostare core.autocrlf=true.

Ho fatto un nuovo checkout con core.autocrlf=truee ora non ricevo quei messaggi.

Se stai utilizzando Visual Studio 2017, 2019, puoi:

1. aprire il file .gitignore principale (aggiornare o rimuovere i file .gitignore di altri in altri progetti nella soluzione)
2. incolla il codice qui sotto:

[core]
 autocrlf = false
[filter "lfs"]
 required = true
 clean = git-lfs clean -- %f
 smudge = git-lfs smudge -- %f
 process = git-lfs filter-process

Fai solo una cosa semplice:

1. Apri git-hub (Shell) e vai al file di directory a cui appartiene (cd / a / b / c / ...)
2. Esegui dos2unix (a volte dos2unix.exe)
3. Prova a impegnarti ora. Se ricevi di nuovo lo stesso errore. Esegui tutti i passaggi precedenti tranne che invece di dos2unix, esegui unix2dox (unix2dos.exe qualche volta)