Windows git "advertencia: LF será reemplazado por CRLF", ¿está esa cola de advertencia al revés?

env:

• Windows 7
• msysgit

Wheng I git commit, dice:

warning: LF will be replaced by CRLF. 

¿Es esta cola de advertencia hacia atrás?
Edito el archivo en Windows, el final de la línea es CRLF, al igual que esta foto:

Y git lo cambia LFpor comprometerse con el repositorio.
Entonces creo que la advertencia correcta es:

warning: CRLF will be replaced by LF. 

advertencia: LF será reemplazado por CRLF.

Dependiendo del editor que esté utilizando, un archivo de texto con LF no necesariamente se guardará con CRLF: los editores recientes pueden preservar el estilo EOL. Pero esa configuración de git insiste en cambiar esos ...

Simplemente asegúrese de que (como recomiendo aquí ):

git config --global core.autocrlf false

De esa manera, evita cualquier transformación automática y aún puede especificarlos a través de un .gitattributesarchivo y core.eoldirectivas .

Windows git "LF será reemplazado por CRLF"
¿Esta advertencia está hacia atrás?

No: estás en Windows, y la git configpágina de ayuda menciona

Utilice esta configuración si desea tener CRLFterminaciones de línea en su directorio de trabajo aunque el repositorio no tenga terminaciones de línea normalizadas.

Como se describe en " git reemplazando LF por CRLF ", solo debería ocurrir al finalizar la compra (no commit), con core.autocrlf=true.

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

Como se menciona en la respuesta de XiaoPeng , esa advertencia es la misma que:

advertencia: (si lo revisa o clona en otra carpeta con su core.autocrlfconfiguración actual ), LF será reemplazado por CRLF
El archivo tendrá sus terminaciones de línea originales en su directorio de trabajo (actual).

Como se menciona en el git-for-windows/gitnúmero 1242 :

Todavía siento que este mensaje es confuso, el mensaje podría extenderse para incluir una mejor explicación del problema, por ejemplo: "LF será reemplazado por CRLF file.jsondespués de eliminar el archivo y volver a revisarlo".

Nota: Git 2.19 (septiembre de 2018), cuando se usa core.autocrlf, la advertencia falsa "LF será reemplazado por CRLF" ahora se suprime .

Como quaylar comenta correctamente , si hay una conversión en commit, es LFsolo.

Esa advertencia específica " LF will be replaced by CRLF" proviene de 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);

Es llamado por convert.c#crlf_to_git(), llamado por convert.c#convert_to_git()sí mismo, llamado por sí mismo convert.c#renormalize_buffer().

Y eso último renormalize_buffer()solo es llamado por merge-recursive.c#blob_unchanged().

Por lo tanto, sospecho que esta conversión se produce git commitsolo si dicha confirmación es parte de un proceso de fusión.

Nota: con Git 2.17 (Q2 2018), una limpieza de código agrega alguna explicación.

Ver commit 8462ff4 (13 de enero de 2018) por Torsten Bögershausen ( tboegi) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 9bc89b1 , 13 feb 2018)}

convert_to_git (): safe_crlf / checksafe se convierte en int conv_flags

Al llamar convert_to_git(), el checksafeparámetro definió lo que debería suceder si la conversión EOL ( CRLF --> LF --> CRLF) no se realiza de manera sencilla.
Además, también definió si las terminaciones de línea deben renormalizarse ( CRLF --> LF) o mantenerse como están.

checksafe fue una safe_crlfenumeración con estos valores:

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

Tenga en cuenta que una regresión introducida en 8462ff4 (" convert_to_git(): safe_crlf/checksafeconvierte int conv_flags", 13/01/2018, Git 2.17.0) en el ciclo Git 2.17 provocó que las autocrlfreescrituras produjeran un mensaje de advertencia a pesar de la configuraciónsafecrlf=false .

Ver commit 6cb0912 (04 de junio de 2018) por Anthony Sottile ( asottile) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 8063ff9 , 28 jun 2018)}

SÍ, la advertencia es al revés.

Y, de hecho, ni siquiera debería ser una advertencia en primer lugar. Porque toda esta advertencia dice (pero desafortunadamente al revés) es que los caracteres CRLF en su archivo con terminaciones de línea de Windows serán reemplazados por LF en la confirmación. Lo que significa que está normalizado a las mismas terminaciones de línea utilizadas por * nix y MacOS.

No pasa nada extraño, este es exactamente el comportamiento que normalmente desearía.

Esta advertencia en su forma actual es una de dos cosas:

1. Un error desafortunado combinado con un mensaje de advertencia demasiado cauteloso, o
2. Una trama muy inteligente para hacerte pensar realmente esto ...

;)

- Actualización el 9 de julio ---

Se eliminó "Es correcto y preciso" como comentó @mgiuca

======

NO . NO está hablando de sus archivos actualmente con CRLF. En cambio, se trata de archivos con LF.

Debería leer:

advertencia: ( si lo revisa o clona en otra carpeta con su configuración core.autocrlf actual ), LF será reemplazado por CRLF

El archivo tendrá sus terminaciones de línea originales en su directorio de trabajo ( actual ).

Esta imagen debería explicar lo que significa.

Todo esto supone core.autocrlf=true

Error original:

advertencia: LF será reemplazado por CRLF
El archivo tendrá sus terminaciones de línea originales en su directorio de trabajo.

Lo que DEBE leer el error:

advertencia: LF será reemplazado por CRLF en su directorio de trabajo
El archivo tendrá sus terminaciones de línea LF originales en el repositorio git

Explicación aquí :

El efecto secundario de esta conveniente conversión, y de esto se trata la advertencia que está viendo, es que si un archivo de texto que creó originalmente tenía terminaciones LF en lugar de CRLF, se almacenará con LF como de costumbre, pero cuando se verifica más tarde tendrá terminaciones CRLF. Para archivos de texto normales, esto suele estar bien. La advertencia es un "para su información" en este caso, pero en caso de que git evalúe incorrectamente que un archivo binario sea un archivo de texto, es una advertencia importante porque git estaría corrompiendo su archivo binario.

Básicamente, un archivo local que anteriormente era LF ahora tendrá CRLF localmente

git config --global core.autocrlf false funciona bien para configuraciones globales.

Pero si está utilizando Visual Studio, es posible que también deba modificar .gitattributesalgún tipo de proyecto ( por ejemplo, la aplicación de biblioteca de clase c # ):

• eliminar línea * text=auto

Después de configurar core.autocrlf=true, estaba obteniendo "LF será reemplazado por CRLF" (nota no "CRLF será reemplazado por LF") cuando estaba editando git add(¿o tal vez estaba encendido git commit?) Archivos editados en Windows en un repositorio (que sí usa LF) que se verificó antes de configurar core.autocrlf=true.

Hice un nuevo pago con core.autocrlf=truey ahora no recibo esos mensajes.

Si está utilizando Visual Studio 2017, 2019, puede:

1. abra el .gitignore principal (actualice o elimine otros archivos .gitignore en otros proyectos de la solución)
2. pegue el siguiente código:

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

Haz una cosa simple:

1. Abra git-hub (Shell) y navegue hasta el archivo de directorio al que pertenece (cd / a / b / c / ...)
2. Ejecute dos2unix (a veces dos2unix.exe)
3. Intenta comprometerte ahora. Si obtiene el mismo error nuevamente. Realice todos los pasos anteriores, excepto en lugar de dos2unix, haga unix2dox (unix2dos.exe en algún momento)