Git, agregar archivos al repositorio genera un error fatal para LF -> CRLF

Question

Soy nuevo en git y necesito ayuda. Estoy usando msysgit en Windows.

Cuando ejecuto el comando git add [folderName] tengo la respuesta:

fatal: LF would be replaced by CRLF in [.css file or .js file] 

y luego, si se intenta hacer un commit 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 fueron descargados de la red, así que supongo que por eso la tienen LF. Si abro el archivo y corté/pegué el contenido, entonces aparece el error en el siguiente archivo, y así sucesivamente.

Cualquier ayuda será muy apreciada.

Editar

Configuración core.autocrlf en false parece resolver el problema, pero he leído en muchos puestos de no establecer esta opción en false.

¿Alguien me puede indicar dónde puedo encontrar los problemas que pueden surgir en esta situación?

Answer 1

Confíe en los editores de código para manipular sus 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 las terminaciones de su línea, no lo haga. Esto lastimará.

Reiterando a partir de una respuesta aceptada: "A menos que pueda ver un tratamiento específico que deba tratar con eol nativo, es mejor dejar autocrlf en falso".

También desde el libro progit al final de la sección sobre autocrlf:

"Si eres un programador de Windows haciendo un proyecto sólo para Windows, a continuación, puede desactivar esta funcionalidad, el carro vuelve a grabar en el repositorio estableciendo el valor de configuración en false"

la única ayuda que puedo dar es que si se toma la otra ruta, familiarizarse con vim -b que mostrará caracteres especiales como el CR en msysgit y git show HEAD:path/to/your/file.txt cuales debería mostrarle el archivo en la forma en que git lo almacenó.

Establecer core.whitespace cr-at-eol para tener parches y diffs que no resaltan los CR como posibles espacios en blanco problemáticos.

No vale la pena la molestia. Tienda tal cual.

Answer 2

Probablemente el problema se deba a que configura Git para almacenar archivos internamente con crlf con la configuración core.eol. Cuando agrega un archivo, Git le advierte que lo cambiará al formato interno.

Git funciona mejor con lf terminaciones de línea, por lo que si es posible, siempre trabaje con core.eol = lf.

Esto debe explicar cuándo utilizar core.autocrlf, Why should I use core.autocrlf=true in Git?

También puede que quiera usar core.safecrlf. Consulte git config --help para obtener detalles sobre la configuración.

Answer 3

muy nuevo en esto, por lo que establecer core.autocrlf en false no tiene demasiado sentido para mí. Así que para otros novatos, vaya al archivo de configuración en el que .git carpeta y agrega:

[core] 
    autocrlf = false 

bajo el título [core].

Answer 4

La autodetección git de formatos funciona bastante bien. Por lo tanto, core.autocrlf=true es una muy buena idea en Windows.

Decir git config --global core.safecrlf=false dice a Git: Hola, por favor convertir mis equivocadas finales de línea (LF solamente) a finales de línea de Windows (CRLF) y no me molesta con él.

Por lo tanto, realmente debería deshabilitar core.safecrlf. respuesta

más largo en: https://stackoverflow.com/a/15471083/873282