usuario619656
Soy nuevo en git y necesito ayuda. Estoy usando msysgit en Windows.
Cuando ejecuto el comando git add [folderName] me sale la respuesta:
fatal: LF would be replaced by CRLF in [.css file or .js file]
y luego, si intentas hacer un compromiso, no pasa nada.
$ git commit
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# so01/
nothing added to commit but untracked files present (use "git add" to track)
Algunos de estos archivos css/js se descargaron de la red, así que supongo que es por eso que tienen LF. Si abro el archivo y corto/pego el contenido, aparece el error en el siguiente archivo y así sucesivamente.
Cualquier ayuda será muy apreciada.
Editar
Ajuste core.autocrlf a falso parece resolver el problema, pero leí en muchas publicaciones que no establezca esta opción en falso.
¿Alguien puede indicarme dónde puedo averiguar qué problemas pueden surgir en esta situación?
muy nuevo en esto, por lo que establecer core.autocrlf en falso no tenía mucho sentido para mí. Entonces, para otros novatos, vaya al archivo de configuración en su carpeta .git y agregue:
[core]
autocrlf = false
bajo la [core] Bóveda.
adam dimitruk
Confíe en los editores de código para manipular los finales de línea. Auto crlf debe ser falso. No permita que el control de fuente se vuelva demasiado inteligente. Si no necesita tener su herramienta de control de fuente para cambiar los finales de línea, no lo haga. Esto dolerá.
Para reiterar a partir de una respuesta aceptada: “A menos que pueda ver un tratamiento específico que deba tratar con eol nativo, es mejor que deje autocrlf en falso”.
También del libro progit al final de la sección sobre autocrlf:
“Si es un programador de Windows que realiza un proyecto solo para Windows, puede desactivar esta funcionalidad y registrar los retornos de carro en el repositorio configurando el valor de configuración en falso”
La única otra ayuda que puedo darte es que si tomas la otra ruta, te familiarices con vim -b que mostrará caracteres especiales como CR en MSysGit, y git show HEAD:path/to/your/file.txt cual debería mostrarle el archivo de la forma en que lo almacenó git.
Establecer core.whitespace cr-at-eol tener parches y diferencias que no resalten los CR como posibles espacios en blanco problemáticos.
No vale la pena molestarse. Almacenar como está.
-
Auto crlf debe ser falso
– prusswan
28 de diciembre de 2011 a las 12:39
-
sí, es cierto en Windows. Nuevamente, no haga nada más que autocrlf = false. He estado haciendo esto durante los últimos 4 años con varios equipos en Windows/.net. Puede hacer otras cosas para caerse y lastimarse. Eventualmente establecerá autocrlf en falso.
– Adam Dimitruk
28 de diciembre de 2011 a las 20:37
-
¿Por qué su evidencia anecdótica específica de Windows/.net es más importante que otras y qué se recomienda en progit.org/book/ch7-1.html?
– prusswan
29 de diciembre de 2011 a las 2:59
-
Todavía es anecdótico, mi punto de vista como usuario principal de Windows que trabaja en equipos donde se usan múltiples sistemas operativos es que la documentación es correcta y depende mucho del repositorio. Establecer a ciegas core.autocrlf en falso no es el tipo de consejo que debería estar dando, es simplemente información errónea.
– prusswan
29 de diciembre de 2011 a las 6:02
-
El OP que indica que es un proyecto solo de Windows no es una razón plausible para defender eso
core.autocrlf=falsesiempre se debe usar. Apenas entiendo su razonamiento de que el desarrollo multiplataforma es la excepción a la regla, muchos desarrolladores participarán en proyectos con diferentes arquitecturas, especialmente en el mundo de Java donde no se usacore.autocrlf=falsese vuelve problemático cuando los editores luchan por el final de línea. Visual Studio también tiene la molestia adicional de que solo cambia los finales de línea en las partes de los archivos que edita y no en todo el archivo.–Bret Ryan
4 de julio de 2012 a las 12:12
motivo
El problema probablemente se debe a que configuró Git para almacenar archivos internamente con crlf con el core.eol ajuste. Cuando agrega un archivo, Git le advierte que lo cambiará al formato interno.
Git funciona mejor con lf terminaciones de línea, así que si es posible siempre trabaje con core.eol = lf.
Esto debería explicar cuándo usar core.autocrlf¿Por qué debo usar core.autocrlf=true en Git?
También puede querer usar core.safecrlf. Controlar git config --help para obtener detalles sobre la configuración.
-
La respuesta a la que se vinculó dice: “A menos que pueda ver un tratamiento específico que deba tratar con EOL nativo, es mejor que deje autocrlf en falso”.
– Adam Dimitruk
28 de diciembre de 2011 a las 20:40
-
No estoy seguro de por qué recibí un voto negativo por esto. ¿Me he perdido algo? @AdamDymitruk También da un par de casos en los que podría usarse. Creo que es útil saber por qué la opción está allí (si nunca debo usarla, ¿por qué puedo configurarla?)
– motivo
29 de diciembre de 2011 a las 11:45
koppor
La detección automática de formatos de git funciona bastante bien. Por lo tanto, core.autocrlf=true es una muy buena idea en Windows.
Dicho git config --global core.safecrlf=false le dice a git: Oye, por favor convierte mi equivocado finales de línea (solo LF) a finales de línea de Windows (CRLF) y no me moleste con eso.
Por lo tanto, realmente debería deshabilitar core.safecrlf.
Respuesta más larga en: https://stackoverflow.com/a/15471083/873282
¿Está trabajando con otros que están en un entorno que no es de Windows?
– Adam Dimitruk
28 de diciembre de 2011 a las 20:42
No. Estoy trabajando en una pequeña aplicación que pondré en appharbor. Hasta ahora todo bien, pero quería saber cuál es la diferencia en esas opciones. Después de terminar la aplicación, planeo investigar un poco, pero mientras tanto, creo que usaré SO para una solución rápida.
– usuario619656
29 de diciembre de 2011 a las 0:36
Entonces, razón de más para establecer autocrlf en falso. No necesitas el dolor de cabeza. Tenga los archivos confirmados como están. Es una pena que la configuración predeterminada al instalar msysgit tome la peor opción.
– Adam Dimitruk
29 de diciembre de 2011 a las 1:02