git reemplazando LF con CRLF

840

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.

git

— mrblah
fuente

14

@apphacker porque estandarizar los finales de línea es menos molesto que tener que cambiarlos usted mismo al diferenciar dos archivos. (Y, por supuesto, si no está de acuerdo, puede desactivar la función core.autocrlf).

— RJFalconer

2

¿Por qué serían diferentes los finales de línea a menos que se tocara la línea completa

— Bjorn

3

A menudo toco muchas líneas, porque estoy experimentando con diferentes ideas, agregando declaraciones de seguimiento para ver cómo funcionan, etc. Entonces podría querer solo realizar un cambio en dos o tres líneas e ignorar completamente a las demás porque yo los había vuelto a poner como los encontré (o eso creía).

— MatrixFrog el

55

@MatrixFrog: su editor parece roto, incapaz de detectar automáticamente las terminaciones de línea. Cual es Trabajo en proyectos híbridos que deben tener algunos archivos LF y otros archivos CRLF en el mismo repositorio. No es un problema para ningún editor moderno. Tener el control de versiones (o transferencia de archivos) con terminaciones de línea para evitar las limitaciones del editor es la peor idea de la historia, lo cual es obvio por la mera extensión de las explicaciones a continuación.

— MarcH

44

El único editor moderno que conozco que hace algo incorrecto es Visual Studio. Visual Studio abrirá felizmente un archivo con terminaciones de línea LF. Si luego inserta nuevas líneas, insertará CRLF y guardará las terminaciones de líneas mixtas. Microsoft se niega a arreglar esto, lo cual es una gran mancha en un IDE bastante bueno: - (

— Jon Watte

957

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.

— Antony Hatchkins
fuente

28

Por la cantidad de tiempo que he pasado para llegar hasta aquí, esperaba un core.crlf = rackoff ;-)

— PandaWood

10

Reestructuré el contenido, tal vez sea más fácil de leer de esta manera

— Antony Hatchkins

77

lo siento, espero que mi comentario no haya sido tomado como una crítica a su respuesta. Por "llegar tan lejos" quiero decir, antes de encontrar esta respuesta.

— PandaWood

10

Esto es muy confuso. Tengo LF configurado en mi editor. Todo el código de repositorio utiliza LF. global autocrlf se establece en falso y el núcleo gitconfig en mi directorio de inicio se establece en falso. Pero todavía recibo el mensaje LF siendo reemplazado por CRLF

— isimmons

17

Si ha configurado su editor para usar terminaciones de estilo Unix, ¿por qué no configurarlo core.autocrlfcomo entrada? Por lo que deduje de su respuesta, configurarlo como entrada asegura que el repositorio y el directorio de trabajo siempre tengan finales de línea de estilo unix. ¿Por qué nunca querrías eso en Windows?

— Hubro

764

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".

— Andrew Arnott
fuente

116

Como se dijo aquí ( stackoverflow.com/questions/1249932/… ), respetuosamente estaría en desacuerdo y dejaría esa configuración en OFF (y usaría Notepad ++ o cualquier otro editor capaz de tratar, y dejar como está, cualquier carácter de línea final encuentra)

— VonC

23

Me gusta esta respuesta, y prefiero dejar autocrlf establecido en verdadero. Como alternativa, ¿hay alguna forma de eliminar los mensajes de advertencia automáticamente?

— Krisc

12

Sería bueno aumentar esta respuesta bien escrita con una comparación de la core.eolconfiguración, tal vez en concierto con la .gitattributesconfiguración. He estado tratando de descubrir las diferencias y las superposiciones a través de la experimentación, y es muy confuso.

— seh

55

Para una solución más permanente, cambie su .gitconfig a: [core] autocrlf = false

— RBZ

99

¿Hay alguna manera fácil de silenciar la advertencia? Quiero que sea verdad y sé que lo he puesto a verdad. No necesito ver todas las advertencias todo el tiempo ... Está bien, de verdad ...: p

— UmaN

160

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.

— usuario2630328
fuente

23

Gracias por una manera simple, multiplataforma y clara de ARREGLO, en lugar de una gran discusión sobre el significado de la configuración.

— Eris

2

si git reset --hard ¿es posible que se pierda mi cambio local? Solo sigo toda la mención de comentarios anterior

— Freddy Sidauruk

55

Sí, sus cambios locales se perderán. El parámetro --hard restablece el índice y el árbol de trabajo, por lo que cualquier cambio en los archivos rastreados se descartará. git-scm.com/docs/git-reset

— Jacques

2

¿Cuál es el significado de git rm --cached -r .? ¿Por qué git reset --hardno es suficiente?

— gavenkoa

2

@gavenkoa @max Necesita el git rm --cached -r .Si lo hace git reset --harddespués de cambiar la core.autocrlfconfiguración, no volverá a convertir las terminaciones de línea. Necesitas limpiar el índice git.

— wisbucky

80

git config core.autocrlf false

— Arun
fuente

66

asegúrese de ejecutar esta raíz del repositorio interno

— Hammad Khan

23

No entiendo cómo esto puede ser útil. La mitad de las personas requieren que el autocrlf sea verdadero para que funcione, la otra mitad necesita que sea falso / input. Entonces, ¿qué, se supone que tiran al azar estas respuestas únicas en la pared de su consola hasta que algo se pega y "funciona"? Esto no es productivo.

— Zoran Pavlovic

Me sale un error "fatal: no en un directorio git". Traté de cd a C: \ Archivos de programa \ Git y C: \ Archivos de programa \ Git \ bin

— pixelwiz

2

@mbb el establecimiento autcrlfde falselas bateas sólo el tema a todos los usuarios de su proyecto.

— jpaugh

55

@pixelwiz: este comando configura la propiedad solo para el proyecto (por lo que debe estar bajo un repositorio git para ejecutarlo). Si desea configurar esto globalmente, use git config --global core.autocrlf falseen su lugar.

— Michaël Polla

49

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.

— Rifat
fuente

8

¿Qué hace?

— Salman von Abbas

1

Esto es lo que dice la opción de ayuda: `--u2d, -D realizar UNIX -> Conversión DOS`

— Larry Battle

1

@ Rifat estoy confundido. Su comentario dice que dos2unix -Dconvertirá las terminaciones de línea de Windows en terminaciones de línea de Linux. ¿No es lo mismo que la conversión de DOS (CRLF) -> UNIX (LF)? Sin embargo, dos2unix -hafirma que -Drealizará la conversión de UNIX (LF) -> DOS (CRLF). dos2unix Más información: gopherproxy.meulie.net/sdf.org/0/users/pmyshkin/dos2unix

— Larry Battle

1

@LarryBattle Sí, tienes razón sobre -D. En realidad, publiqué la respuesta cuando era un usuario de Windows. Y hice el comentario más de un año después cuando soy usuario de mac: D BTW, gracias por la aclaración.

— Rifat

1

Esto funcionó para mí. Estoy usando Cygwin, que no parece admitir el modificador -D, pero existe el comando "unix2dos", que hace lo mismo. Sin embargo, desearía saber qué causó el problema: tengo core.autocrlf = false y es un repositorio exclusivo de Windows.

— Richard Beier

28

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).

— Yevgeny Simkin
fuente

1

Debería ser safecrlf(con una 'f')

— alpipego

22

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.

— Gene Pavlovsky
fuente

Ahora me encuentro con esto, tratando de administrar un repositorio con scripts de Cygwin entre otros archivos de texto básicos. ¿Cómo manejaría archivos sin extensión (por ejemplo, "fstab", "sshd_config")? El artículo vinculado no cubre ese escenario.

— Mike Loux

1

@MikeLoux Pruebe este método: stackoverflow.com/a/44806034/4377192

— Gene Pavlovsky

Descubrí que text=false eol=falsefuncionaba de manera similar a binary. ¿Eso suena bien? Puede ser útil indicar "Sé que estos son archivos de texto, pero no quiero que se normalicen"

— joeytwiddle

19

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

:set noendofline binary
:wq

— Roman Rhrn Nesterov
fuente

2

Simplemente editar con vimdejaría toda la línea terminada intacta.

— Ojo

He tenido este problema con algunos archivos de Cocoapods. Lo anterior solucionó la mayoría de ellos; por lo demás, s / {control-v} {control-m} // hizo el truco. Los dos códigos de control juntos hacen la ^ M que aquellos de nosotros en OS X a menudo vemos en los archivos de Windows.

— Janineanne

16

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:

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
Establezca autocrlf en falso e ignore el hecho de que las terminaciones de línea no están en el estilo preferido de git
Revise sus archivos con autocrlf desactivado, arregle todas las terminaciones de línea, verifique todo nuevamente y vuelva a encenderlo.
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.

— Tim Abell
fuente

2

Creo que hay una cuarta opción para agregar a su lista, suponiendo que uno pueda permitirse reescribir el historial: puede tomar un repositorio git que creó inicialmente con git-svn y reescribir su historial para que ya no tenga saltos de línea CRLF. Esto le proporcionaría saltos de línea normalizados que se extienden hacia atrás a través de todo su historial de svn. El usuario keo presenta una solución en stackoverflow.com/a/1060828/64257 .

— Chris

Acerca de su nota al pie: rebaseno tiene ningún problema con CRLF. El único problema que conozco es que la herramienta de combinación de git estándar insertará sus marcadores de conflicto ("<<<<<<", ">>>>>>" etc.) solo con LF, por lo que un archivo con marcadores de conflicto tienen terminaciones de línea mixtas. Sin embargo, una vez que elimine los marcadores, todo estará bien.

— sleske

Es posible que el manejo de git haya cambiado en los últimos 3 años, esta fue mi experiencia directa con él en ese momento, no he tenido que revisar este problema en particular desde entonces. ymmv.

— Tim Abell el

1

@sleske begin git 2.8, los marcadores de combinación ya no introducirán el final de línea mixta. Ver stackoverflow.com/a/35474954/6309

— VonC

@VonC: Eso es genial. Es bueno saber para las veces que necesito trabajar en Windows.

— sleske

12

Eliminando lo siguiente del archivo ~ / .gitattributes

* text=auto

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

— basiloungas
fuente

66

Incorrecto. Esa línea, si está presente, anulará la configuración de core.autocrlf. Si se establece en 'verdadero', entonces no, eliminar esa línea no evitará que git verifique las terminaciones de línea.

— Arafangion

1

No obstante, si core.autocrlf está configurado en false, si este no se elimina, establecer el autocrlf en falso no ayudará mucho, por lo que este me ayudó (pero por sí solo no es suficiente).

— Matty

2

¡Votar esto! Si bien la parte "evitará que git verifique" no es técnicamente correcta, esta es la ÚNICA respuesta que menciona específicamente la text=configuración .gitattributes(que, si está presente, SERÁ un bloqueador). Entonces las otras respuestas están incompletas. Me estaba volviendo loco tratando de descubrir por qué mis archivos seguían apareciendo como "modificados", sin importar cuántas veces cambié mi configuración autocrlfy mi safecrlfconfiguración, y desprotegido y borrado el caché de git y el restablecimiento completo.

— jdunk

10

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.

— Xiao Peng - ZenUML.com
fuente

También significa que lo que se envía a Subversion (si lo hace) tendrá la conversión.

— jpaugh

10

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.

— Michael Ribbons
fuente

2

Esto es especialmente útil cuando desea convertir entre CRLF y LF, pero tiene algunos archivos .sh que deben permanecer intactos. Yo uso *.sh -crlftodo el tiempo ...

— MartinTeeVarga

9

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.

— Joey Adams
fuente

55

Como nadie parece haberlo dicho, CR significa "retorno de carro" y LF significa "avance de línea". Como segunda nota, muchos editores de Windows cambiarán silenciosamente un archivo de texto con el carácter LF que indica una nueva línea para que sea el par de caracteres CRLF. El usuario del editor ni siquiera será advertido, pero Git verá el cambio.

— user2548343

7

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).

— hyvi tan
fuente

Creo que querías decir que tenías git 2.17.1. Estaba teniendo el mismo problema e hice la actualización y esto también lo solucionó. Me alegro de haber visto tu respuesta!

— Phillip McMullen

5

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

— 1991tama1991
fuente

1

También intente usar git config --global core.autocrlf falsepara evitar que Git establezca las terminaciones de línea Unixen una confirmación. Realice un seguimiento con git config core.autocrlfpara verificar que, de hecho, esté establecido en falso.

— Contango

5

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

— tiltedtimmy
fuente

3

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:

— JBallin
fuente

2

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

— Ronan
fuente

2

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.

— Kshitiz
fuente

0

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.

— Hartmut Schorrig
fuente