remove - git rename tag
git reemplazando LF con CRLF (18)
- Abra el archivo en el Bloc de notas ++.
- Vaya a Editar / Conversión EOL.
- Haga clic en el formato de Windows.
- Guarda el archivo.
Ejecutando git en una máquina con Windows XP, usando bash. Exporté mi proyecto desde SVN y luego cloné un repositorio simple.
Luego pegué la exportación en el directorio de repositorios descargados, e hice un:
git add -A
Entonces recibí una lista de mensajes que decían:
LF será reemplazado por CRLF
¿Cuáles son las ramificaciones de esta conversión? Esta es una solución .NET en Visual Studio.
Creo que la answer @ Basiloungas está cerca pero fuera de fecha (al menos en Mac).
Abra el archivo ~ / .gitconfig y establezca safecrlf en falso
[core]
autocrlf = input
safecrlf = false
Eso * lo hará ignorar el final de la línea de caracteres al parecer (funcionó para mí, de todos modos).
Eliminando lo siguiente del archivo ~ / .gitattributes
* text=auto
evitará que git verifique los finales de línea en primer lugar.
En un indicador de shell de GNU / Linux, los comandos dos2unix y unix2dos le permiten convertir / formatear fácilmente sus archivos provenientes de MS Windows
En vim abra el archivo (por ejemplo :e YOURFILE ENTER ), luego
:set noendofline binary
:wq
Estos mensajes se deben al valor predeterminado incorrecto de core.autocrlf en Windows.
El concepto de autocrlf es manejar las conversiones de finales de línea de forma 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 funciona el autocrlf :
core.autocrlf=true: core.autocrlf=input: core.autocrlf=false:
repo repo repo
^ V ^ V ^ V
/ / / / / /
crlf->lf lf->crl crlf->lf / / /
/ / / / / /
Aquí crlf = marcador de fin de línea de estilo ganador, lf = estilo unix (y mac osx).
(Pre-osx cr no está afectado por ninguna de las tres opciones anteriores)
¿Cuándo aparece esta advertencia (bajo Windows)?
- autocrlf = true si tiene el estilo de Unix lf en uno de sus archivos (= RARAMENTE),
- autocrlf = input si tiene un estilo de crlf en uno de sus archivos (= casi SIEMPRE),
- autocrlf = false - ¡NUNCA!
¿Qué significa esta advertencia?
La advertencia " LF será reemplazado por CRLF " dice que usted (teniendo autocrlf = true ) perderá su LF de estilo Unix después del ciclo de autocrlf compromiso (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 (teniendo autocrlf = input ) perderá su CRLF de estilo Windows después de un ciclo de autocrlf compromiso (será reemplazado por LF de estilo Unix). No utilice la input debajo de las ventanas.
Otra forma de mostrar cómo funciona el autocrlf
1) true: x -> LF -> CRLF
2) input: x -> LF -> LF
3) false: x -> x -> x
donde 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.autocrlf se selecciona durante la instalación de git y se almacena en gitconfig de todo el sistema ( %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/config o $HOME/.config/git/config y
- gitconfig "local" (por repo) en .git/config en el directorio de trabajo.
Entonces, escriba git config core.autocrlf en el directorio de trabajo para verificar el valor actualmente usado y
- agregue autocrlf=false a la solución gitconfig # por sistema de todo el sistema
- git config --global core.autocrlf false # solución por usuario
- git config --local core.autocrlf false # solución por proyecto
Advertencias
- La git config puede ser anulada por la configuración de gitattributes .
- crlf -> lf conversión solo ocurre cuando se agregan nuevos archivos, los archivos crlf que ya existen en el repositorio no se ven afectados.
Moraleja (para Windows):
- use core.autocrlf = true si planea usar este proyecto también en Unix (y no desea configurar su editor / IDE para usar finales de línea de Unix),
- use core.autocrlf = false si planea usar este proyecto solo en Windows (o si ha configurado su editor / IDE para que use finales de línea unix),
- nunca use core.autocrlf = input menos que tenga una buena razón para hacerlo ( por ejemplo, si está usando las utilidades de Unix en Windows o si se encuentra con problemas de makefiles),
PS ¿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. Elija el tercero ( Checkout tal como está, confirme como está ). No verás este mensaje. Siempre.
PPS Mi preferencia personal es configurar el editor / IDE para usar terminaciones de estilo Unix, y establecer core.autocrlf en false .
Git tiene tres modos de cómo trata los finales 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 true o false a la línea de comando anterior.
Si core.autocrlf se establece en verdadero, eso significa que cada vez que agregue un archivo al repositorio de git que git cree que es un archivo de texto, todas las terminaciones de línea CRLF se convertirán en solo LF antes de almacenarlas en la confirmación. Cada vez que git checkout algo, todos los archivos de texto automáticamente tendrán sus finales de línea LF convertidos a finales CRLF. Esto permite el desarrollo de un proyecto a través de plataformas que utilizan diferentes estilos de final de línea sin que los compromisos sean muy ruidosos 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 usted creó originalmente tenía terminaciones LF en lugar de CRLF, se almacenará con LF como siempre, pero cuando se verifique Más tarde tendrá terminaciones CRLF. Para los archivos de texto normales, esto normalmente está bien. La advertencia es "para su información" en este caso, pero en el 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.autocrlf se establece en falso, nunca se realiza una conversión de final de línea, por lo que los archivos de texto se verifican tal como están. Esto generalmente funciona bien, siempre y cuando todos sus desarrolladores estén en Linux o en Windows. Pero en mi experiencia, todavía tiendo a obtener archivos de texto con finales de líneas 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".
La pregunta de OP está relacionada con Windows y no pude 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
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 devolución predeterminado en Windows, mientras que LF es el formato de devolución predeterminado para la mayoría de los demás sistemas operativos.
Es probable 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 los archivos binarios intactos en lugar de tratar de convertir LF a CRLF en, por ejemplo, JPEG.
En resumen, es probable que no tenga que preocuparse demasiado por esta conversión. Sin embargo, si va a archivar su proyecto como un archivo, otros codificadores probablemente apreciarían tener terminadores de línea LF en lugar de CRLF. Dependiendo de cuánto te importe (y de que no utilices el Bloc de notas), es posible que desees configurar git para que use las devoluciones LF si puedes :)
Apéndice: CR es el código ASCII 13, LF es el código ASCII 10. Por lo tanto, CRLF es de dos bytes, mientras que LF es uno.
Para corregir el problema, es decir, para evitar recibir mensajes de error.
git config core.autocrlf false
Esto es para GitBash en Windows. Espero eso ayude :-)
Si ya ha revisado el código, los archivos ya están indexados. Después de cambiar la configuración de git, debe actualizar los índices con
git rm --cached -r .
y reescribir el índice git con
git reset --hard
Tanto unix2dos como dos2unix están disponibles en windows 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 filename no funcionará con todos los sistemas operativos. Por favor revise este enlace para la compatibilidad.
Si, por algún motivo, necesita forzar el comando, use --force . Si dice inválido entonces use -f .
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 los finales de línea CRLF intactos. Si luego usa git-svn para poner el proyecto en git, entonces las terminaciones CRLF persisten en el repositorio de git, que no es el estado en el que se espera encontrar git; el valor predeterminado es que solo tenga terminaciones de línea unix / linux (LF) registrado en
Cuando luego verifica los archivos en Windows, la conversión autocrlf deja los archivos intactos (ya que tienen los finales correctos 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, resulta en comparar lo que cree que es un LF en el archivo desprotegido con un CRLF inesperado en el repositorio.
Por lo que puedo ver tus elecciones son:
- Vuelva a importar su código a un nuevo repositorio de git sin usar git-svn, esto significará que los finales de línea se convierten en la confirmación inicial de git --todos
- Establezca autocrlf en false e ignore el hecho de que los finales de línea no están en el estilo preferido de git
- Revise sus archivos con la función Autocrlf desactivada, corrija todos los finales de línea, vuelva a revisar todo 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 # 2, entonces mi experiencia es que algunas de las herramientas auxiliares (rebase, parche, etc.) no manejan los archivos CRLF y terminará tarde o temprano con archivos con una combinación de CRLF y LF (línea inconsistente terminaciones). No conozco ninguna manera de obtener lo mejor de ambos.
http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/
echo "* -crlf"> .gitattributes
Haga esto en una confirmación separada o git podría seguir viendo archivos completos modificados cuando realice un solo cambio (dependiendo de si ha cambiado la opción autocrlf)
Este realmente funciona. Git respetará los finales de línea en proyectos de final de línea mixtos y no le advertirá sobre ellos.
El artículo de GitHub sobre los finales de línea se menciona comúnmente cuando se habla de este tema.
Mi experiencia personal con el uso de la configuración de configuración core.autocrlf 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 scripts de shell bash , que requieren finales de línea UNIX (LF).
Usando la configuración core.autocrlf recomendada de core.autocrlf para Windows, si core.autocrlf 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 verifican con Finales de línea de Windows (CRLF), creando problemas.
Básicamente, para un entorno mixto como el que tengo, establecer el core.autocrlf en cualquiera de las opciones no funcionará bien en algunos casos. Esta opción podría configurarse en una configuración git local (repositorio), pero incluso eso no sería lo suficientemente bueno para un proyecto que contenga cosas relacionadas con Windows y UNIX (por ejemplo, tengo un proyecto de Windows con algunos scripts de utilidades de bash ).
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 de cosas para 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.
git config core.autocrlf false