git reemplazando LF con CRLF

Ejecutando git en una máquina con Windows XP, usando bash. Exporté mi proyecto desde SVN y luego cloné un repositorio desnudo.

Luego pegué la exportación en el directorio de repositorios desnudos e hice un:

git add -A

Luego recibí una lista de mensajes que decía:

LF será reemplazado por CRLF

¿Cuáles son las ramificaciones de esta conversión? Esta es una solución .NET en Visual Studio.

Estos mensajes se deben a un valor predeterminado incorrecto de core.autocrlfen Windows.

El concepto de autocrlfes manejar conversiones de terminaciones de línea de manera transparente. Y lo hace!

Malas noticias : el valor debe configurarse manualmente.
Buenas noticias : solo debe hacerse UNA vez por instalación de git (también es posible la configuración por proyecto).

Cómo autocrlffunciona :

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

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

Aquí crlf= marcador de fin de línea estilo win, lf= estilo unix (y mac osx).

(pre-osx crno se ve afectado por ninguna de las tres opciones anteriores)

¿Cuándo aparece esta advertencia (en Windows)

    - autocrlf= truesi tiene estilo unix lfen uno de sus archivos (= RARAMENTE),
    - autocrlf= inputsi tiene estilo win crlfen uno de sus archivos (= casi SIEMPRE),
    - autocrlf= false- ¡NUNCA!

¿Qué significa esta advertencia?

La advertencia " LF será reemplazado por CRLF " dice que usted (tener autocrlf= true) perderá su LF de estilo Unix después del ciclo de confirmación de compra (será reemplazado por CRLF de estilo Windows). Git no espera que uses LF de estilo unix en Windows.

La advertencia " CRLF será reemplazado por LF " dice que usted (tener autocrlf= input) perderá su CRLF de estilo Windows después de un ciclo de confirmación de compra (será reemplazado por LF de estilo Unix). No lo use inputdebajo de las ventanas.

Otra forma más de mostrar cómo autocrlffunciona

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

dónde x es CRLF (estilo Windows) o LF (estilo Unix) y las flechas representan

file to commit -> repository -> checked out file

Como arreglar

El valor predeterminado para core.autocrlfse selecciona durante la instalación de git y se almacena en todo el sistema gitconfig ( %ProgramFiles(x86)%\git\etc\gitconfig). También hay (en cascada en el siguiente orden):

   - gitconfig "global" (por usuario) ubicado en ~/.gitconfig, otro más
   - gitconfig "global" (por usuario) en $XDG_CONFIG_HOME/git/configo $HOME/.config/git/configy
   - "local" (por repo) .git/configen el directorio de trabajo.

Entonces, escribe git config core.autocrlf en el directorio de trabajo para verificar el valor utilizado actualmente y

   - agregar autocrlf=falsea la solución # por sistema de gitconfig en todo el sistema
   - git config --global core.autocrlf false            # solución por usuario
   - git config --local core.autocrlf false              # por proyecto

Advertencias
: la git configconfiguración puede ser anulada por la gitattributesconfiguración.
-crlf -> lf conversión solo ocurre al agregar nuevos archivos, los crlfarchivos que ya existen en el repositorio no se ven afectados.

Moral (para Windows):
    - use core.autocrlf= truesi planea usar este proyecto también en Unix (y no está dispuesto a configurar su editor / IDE para usar terminaciones de línea Unix),
    - use core.autocrlf= falsesi planea usar este proyecto solo en Windows ( o ha configurado su editor / IDE para usar terminaciones de línea unix),
    - nunca use core.autocrlf= a inputmenos que tenga una buena razón para hacerlo ( p . ej. si está utilizando utilidades Unix en Windows o si tiene problemas con los archivos MAKE),

PD: ¿Qué elegir al instalar git para Windows?
Si no va a utilizar ninguno de sus proyectos en Unix, no esté de acuerdo con la primera opción predeterminada. Elige el tercero ( Checkout as-is, commit as-is ). No verás este mensaje. Siempre.

PPS Mi preferencia personal es configurar el editor / IDE para usar finales de estilo Unix, y configurarlo core.autocrlfen false.

Git tiene tres modos de cómo trata las terminaciones de línea:

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

Puede configurar el modo para usar agregando un parámetro adicional de trueofalse a la línea de comando anterior.

Si core.autocrlfse establece en verdadero, eso significa que cada vez que agregue un archivo al repositorio de git que git piense que es un archivo de texto, convertirá todas las terminaciones de línea CRLF a solo LF antes de almacenarlo en la confirmación. Cuando ustedgit checkout algo, todos los archivos de texto tendrán automáticamente sus terminaciones de línea LF convertidas en terminaciones CRLF. Esto permite el desarrollo de un proyecto a través de plataformas que usan diferentes estilos de final de línea sin que las confirmaciones sean muy ruidosas porque cada editor cambia el estilo de final de línea ya que el estilo de final de línea siempre es LF.

El efecto secundario de esta conversión conveniente, 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 generalmente está 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.

Si core.autocrlfse establece en falso, nunca se realiza una conversión de final de línea, por lo que los archivos de texto se registran tal cual. Esto generalmente funciona bien, siempre y cuando todos sus desarrolladores estén en Linux o todos en Windows. Pero en mi experiencia todavía tiendo a obtener archivos de texto con terminaciones de línea mixtas que terminan causando problemas.

Mi preferencia personal es dejar la configuración activada, como desarrollador de Windows.

Consulte http://kernel.org/pub/software/scm/git/docs/git-config.html para obtener información actualizada que incluye el valor de "entrada".

Si ya ha desprotegido el código, los archivos ya están indexados. Después de cambiar la configuración de git, diga ejecutando:

git config --global core.autocrlf input 

deberías actualizar los índices con

git rm --cached -r . 

y reescribir el índice git con

git reset --hard

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

Nota: esto eliminará sus cambios locales, considere guardarlos antes de hacer esto.

git config core.autocrlf false

Tanto unix2dos como dos2unix están disponibles en ventanas con gitbash. Puede usar el siguiente comando para realizar la conversión de UNIX (LF) -> DOS (CRLF). Por lo tanto, no recibirá la advertencia.

unix2dos filename

o

dos2unix -D filename

Pero no ejecute este comando en ningún archivo CRLF existente, entonces obtendrá nuevas líneas vacías cada segunda línea.

dos2unix -D filenameno funcionará con todos los sistemas operativos. Por favor, consulte este enlace para ver la compatibilidad.

Si por alguna razón necesita forzar el comando, use --force. Si dice no válido, úsalo -f.

Creo que la respuesta de @ Basiloungas es cercana pero desactualizada (al menos en Mac).

Abra el archivo ~ / .gitconfig y configúrelo safecrlfen falso

[core]
       autocrlf = input
       safecrlf = false

Eso * hará que ignore el final de la línea char aparentemente (funcionó para mí, de todos modos).

Un artículo de GitHub sobre terminaciones de línea se menciona comúnmente cuando se habla de este tema.

Mi experiencia personal con el uso de la core.autocrlfconfiguración de configuración a menudo recomendada fue muy variada.

Estoy usando Windows con Cygwin, tratando con proyectos de Windows y UNIX en diferentes momentos. Incluso mis proyectos de Windows a veces usan bashscripts de shell, que requieren terminaciones de línea UNIX (LF).

Usando la core.autocrlfconfiguración recomendada de GitHub para Windows, si reviso un proyecto UNIX (que funciona perfectamente en Cygwin, o tal vez estoy contribuyendo a un proyecto que uso en mi servidor Linux), los archivos de texto se extraen con Windows (CRLF ) terminaciones de línea, creando problemas.

Básicamente, para un entorno mixto como el que tengo, establecer el global core.autocrlfen cualquiera de las opciones no funcionará bien en algunos casos. Esta opción podría establecerse en una configuración git local (repositorio), pero incluso eso no sería lo suficientemente bueno para un proyecto que contenga material relacionado con Windows y UNIX (por ejemplo, tengo un proyecto de Windows con algunos bashscripts de utilidad).

La mejor opción que he encontrado es crear archivos .gitattributes por repositorio . El artículo de GitHub lo menciona.
Ejemplo de ese artículo:

# 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

En uno de los repositorios de mi proyecto:

* 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

Es un poco más que configurar, pero hágalo una vez por proyecto, y cualquier colaborador en cualquier sistema operativo no debería tener problemas con los finales de línea cuando trabaje con este proyecto.

En vim abra el archivo (por ejemplo:) :e YOURFILEENTER, luego

:set noendofline binary
:wq

Yo tuve este problema también.

SVN no realiza ninguna conversión de final de línea, por lo que los archivos se confirman con terminaciones de línea CRLF intactas. Si luego usa git-svn para poner el proyecto en git, las terminaciones de CRLF persisten en el repositorio de git, que no es el estado en el que git espera encontrarse; el valor predeterminado es tener solo terminaciones de línea unix / linux (LF) registrado

Cuando luego revisa los archivos en Windows, la conversión de autocrlf deja los archivos intactos (ya que tienen las terminaciones correctas para la plataforma actual), sin embargo, el proceso que decide si hay una diferencia con los archivos registrados realiza la conversión inversa antes de comparar, lo que resulta en comparar lo que cree que es un LF en el archivo desprotegido con un CRLF inesperado en el repositorio.

Hasta donde puedo ver, sus opciones son:

1. Vuelva a importar su código en un nuevo repositorio git sin usar git-svn, esto significará que las terminaciones de línea se convierten en el intial git commit inicial --todos
2. Establezca autocrlf en falso e ignore el hecho de que las terminaciones de línea no están en el estilo preferido de git
3. Revise sus archivos con autocrlf desactivado, arregle todas las terminaciones de línea, verifique todo nuevamente y vuelva a encenderlo.
4. Vuelva a escribir el historial de su repositorio para que la confirmación original ya no contenga el CRLF que git no esperaba. (Se aplican las advertencias habituales sobre la reescritura de la historia)

Nota al pie: si elige la opción n. ° 2, mi experiencia es que algunas de las herramientas auxiliares (rebase, parche, etc.) no hacen frente a archivos CRLF y, tarde o temprano, terminará con archivos con una combinación de CRLF y LF (línea inconsistente) terminaciones). No conozco ninguna forma de obtener lo mejor de ambos.

Eliminando lo siguiente del archivo ~ / .gitattributes

* text=auto

evitará que git verifique los finales de línea en primer lugar.

Debería leer:

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

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

Esta imagen debería explicar lo que significa.

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

echo "* -crlf" > .gitattributes 

Hacer esto en un commit o git separado aún podría ver archivos completos como modificados cuando realiza un solo cambio (dependiendo de si ha cambiado la opción de autocrlf)

Este realmente funciona. Git respetará las terminaciones de línea en proyectos de terminación de línea mixta y no le advertirá sobre ellas.

No sé mucho sobre git en Windows, pero ...

Me parece que git está convirtiendo el formato de retorno para que coincida con el de la plataforma en ejecución (Windows). CRLF es el formato de retorno predeterminado en Windows, mientras que LF es el formato de retorno predeterminado para la mayoría de los otros sistemas operativos.

Lo más probable es que el formato de retorno se ajuste correctamente cuando el código se mueva a otro sistema. También creo que git es lo suficientemente inteligente como para mantener intactos los archivos binarios en lugar de tratar de convertir LF a CRLF en, digamos, JPEG.

En resumen, probablemente no necesite preocuparse demasiado por esta conversión. Sin embargo, si va a archivar su proyecto como un tarball, los codificadores probablemente apreciarían tener terminadores de línea LF en lugar de CRLF. Dependiendo de cuánto le importe (y de no usar el Bloc de notas), es posible que desee configurar git para que use devoluciones LF si puede :)

Apéndice: CR es el código ASCII 13, LF es el código ASCII 10. Por lo tanto, CRLF es dos bytes, mientras que LF es uno.

Asegúrate de haber instalado el último git.
Hice lo anterior git config core.autocrlf false, cuando utilicé git (versión 2.7.1), pero no funcionó.
Entonces funciona ahora cuando actualiza git (de 2.7.1 a 2.20.1).

1. Abra el archivo en el Bloc de notas ++.
2. Vaya a Edición / Conversión EOL.
3. Haga clic en el formato de Windows.
4. Guarda el archivo.

La pregunta de OP está relacionada con Windows y no podría usar otros sin ir al directorio o incluso ejecutar el archivo en Notepad ++ ya que el administrador no funcionó. Así que tuve que seguir esta ruta:

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

Muchos editores de texto le permiten cambiar LF, consulte las instrucciones de Atom a continuación. Simple y explícito.

Haga clic CRLFen la parte inferior derecha:

Seleccione LFen el menú desplegable en la parte superior:

En un indicador de shell GNU / Linux, los comandos dos2unix y unix2dos le permiten convertir / formatear fácilmente sus archivos provenientes de MS Windows

CRLF podría causar algún problema al usar su "código" en dos sistemas operativos diferentes (Linux y Windows). Mi script de Python fue escrito en el contenedor de Docker de Linux y luego fue empujado usando Windows git-bash. Me dio la advertencia de que LF será reemplazado por CRLF. No lo pensé mucho, pero cuando comencé el guión más tarde, decía /usr/bin/env: 'python\r': No such file or directory. Ahora que una \rramificación para ti. Windows usa "CR" - retorno de carro - encima de '\ n' como nuevo carácter de línea - \n\r. Eso es algo que deberías tener en cuenta.

La mayoría de las herramientas en Windows acepta solo LF en archivos de texto. Por ejemplo, puede controlar el comportamiento de Visual Studio en un archivo llamado '.editorconfig' con el siguiente contenido de ejemplo (parte):

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

¡Solo el Bloc de notas original de Windows no funciona con LF, pero hay algunas herramientas de editor simples más apropiadas disponibles!

Por lo tanto, también debe usar LF en archivos de texto en Windows. Este es mi mensaje, ¡muy recomendable! ¡No hay ninguna razón para usar CRLF en Windows!

(La misma discusión está usando \ in include path en C / ++, es una tontería, use #include <pathTo / myheader.h> con slash !, es el estándar C / ++ y todos los compiladores de microsoft lo admiten).

Por lo tanto, la configuración adecuada para git es

git config core.autocrlf false

Mi mensaje: Olvídese de programas de pensamiento tan antiguos como dos2unix y unix2dos. Aclare en su equipo que LF es apropiado para usar bajo Windows.