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

Soy nuevo en el git y necesito un poco de 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, a continuación, si usted trata de 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 se han descargado de la red por lo que supongo que por eso la han LF.
Si abro el archivo y cortar/pegar el contenido, luego me sale el error en el archivo siguiente y así sucesivamente.

Cualquier ayuda será muy apreciada.

Editar

Configuración core.autocrlf a false parece resolver el problema, pero he leído en muchos blogs que no establezca esta opción en false.

Puede alguien que me señale donde puedo averiguar qué problemas pueden surgir en esta situación?

  • Trabajando con otros que están en un no-entorno de windows?
  • No. Estoy trabajando en una pequeña aplicación que voy a poner en appharbor. Por el momento todo está bien, pero yo quería saber ¿cuál es la diferencia en esas opciones. Después de terminar la aplicación pienso hacer algunos reasrch pero en la media hora yo, aunque yo voy a usar, ASÍ que para una solución rápida.
  • A continuación, una razón más para establecer autocrlf a false. Usted no necesita el dolor de cabeza. Tiene los archivos comprometidos como es. Es una lástima que la configuración por defecto cuando se instala msysgit tomar la peor opción.
InformationsquelleAutor user619656 | 2011-12-28

4 Kommentare

  1. 22

    Confianza de los editores de código para manipular los finales de línea. Auto crlf deben ser falsos. No dejes de control de código fuente demasiado inteligente. Si no se necesita tener su origen control de la herramienta para cambiar los finales de línea, no. Esto le va a doler.

    A reiterar desde aceptado la respuesta: «a Menos que pueda ver el tratamiento específico que debe lidiar con los nativos de la eol, es mejor dejar autocrlf a false.»

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

    «Si usted es un programador de Windows haciendo un sólo proyecto, entonces usted puede desactivar esta funcionalidad, el registro de los retornos de carro en el repositorio mediante el ajuste de la configuración del valor en false»

    La única ayuda que puedo dar es que si usted toma el otro camino, familiarizarse con vim -b que se muestran los caracteres especiales tales como el CR en MSysGit, y git show HEAD:path/to/your/file.txt que debe mostrar el archivo en la forma en que git almacena.

    Conjunto core.whitespace cr-at-eol tener los parches y los diffs no resaltar CRs como sea posible problemática en los espacios en blanco.

    No vale la pena la molestia. La tienda tal como es.

    • Auto crlf debe ser false <– Esto no es cierto en windows
    • sí es cierto que en windows. De nuevo, no hacer nada, pero autocrlf = false. He estado haciendo esto durante los últimos 4 años con varios equipos en windows/.net. Usted puede hacer otras cosas para caer y hacerte daño. Eventualmente establecer autocrlf a false.
    • ¿Por qué es su evidencia anecdótica específicos para windows/.neto más importantes que otros, y por lo que se recomienda en progit.org/book/ch7-1.html?
    • Es todavía anecdótica, mi punto de vista como principal usuario de Windows de trabajo en equipos en los que múltiples sistemas operativos se utilizan es que la documentación es correcta y depende mucho del repositorio. Ciegamente configuración del núcleo.autocrlf a falso no es el tipo de consejo que se debe tratar, es simplemente desinformación.
    • leer sus comentarios. Él es el único uso de su solución y es solo para windows. No hay absolutamente ninguna necesidad para que él tiene todas las transformaciones que está hecho para él. Además, de la cruz-plataforma de desarrollo es la excepción y no la regla – especialmente para cualquier persona que utilice msysgit. Esta es apenas la desinformación.
    • +1 a contador downvote: esta respuesta tiene perfecto sentido. @prusswan: por favor, vuelva a leer el Pro Git página usted mismo ha vinculado. Específicamente dice: «Si usted es un programador de Windows haciendo un sólo proyecto, entonces usted puede desactivar esta funcionalidad, el registro de los retornos de carro en el repositorio mediante el ajuste de la configuración del valor a false.» A menos que usted puede apuntar a algunos ejemplos concretos de casos en los que autocrlf=false realmente ha causado problemas en un entorno único, cualquier instrucción establece en verdadero es sólo la carga de culto asesoramiento.
    • El OP que indica que es un windows solo proyecto no es una razón verosímil para advokate que core.autocrlf=false siempre debe ser utilizado. Me cuesta entender tu razonamiento de que la cruz-plataforma de desarrollo es la excepción a la regla, muchos de los desarrolladores que participen en proyectos con diferentes arquitecturas, especialmente en el mundo de Java donde la no utilización de core.autocrlf=false no se vuelven problemáticos como los editores de luchar por la final de línea. Visual Studio también tiene la addded molestia que sólo los cambios de la línea de-terminaciones a las partes de los archivos a editar y no todo el archivo.

  2. 24

    muy nueva en esto, así que la configuración del núcleo.autocrlf a false no tenía mucho sentido para mí. Así que para otros novatos, ir al archivo de configuración en usted .git carpeta y agregar:

    [core]
        autocrlf = false
    

    bajo el [core] título.

  3. 6

    El problema probablemente está ocurriendo porque se establece Git para almacenar archivos internamente con crlf con el core.eol configuración. Cuando se agrega un archivo, Git es advertencia de que se va a cambiar al formato interno.

    Git funciona mejor con lf los finales de línea, así que si es posible trabajar siempre con core.eol = lf.

    Esto debe explicar cuándo utilizar core.autocrlf, ¿Por qué debo utilizar core.autocrlf=true en Git?

    Puede que también desee utilizar core.safecrlf. Compruebe git config --help para obtener detalles sobre la configuración.

    • La respuesta que enlaza a los estados: «a Menos que pueda ver el tratamiento específico que debe lidiar con los nativos de la eol, es mejor dejar autocrlf a false».
    • No estoy seguro de por qué he recibido una downvote para esto? He perdido de algo? @AdamDymitruk también le da un par de casos en los que podría ser utilizado. Creo que es útil saber por qué la opción de allí (si es que nunca lo uso, ¿por qué no puedo configurarlo?)
  4. 0

    El git detección automática de formatos funciona bastante bien. Por lo tanto, core.autocrlf=true es realmente una buena idea sobre Windows.

    Diciendo git config --global core.safecrlf=false dice a git: Oye, por favor, convertir mi mal finales de línea (LF) para Windows finales de línea (CRLF) y no me moleste con ella.

    Por lo tanto, usted realmente debe deshabilitar core.safecrlf.

    Respuesta larga en: https://stackoverflow.com/a/15471083/873282

    • Por favor, poco a explicar por qué usted downvote esta respuesta. Esto ayuda a que (i) a los demás a entender el porqué de esta respuesta no tiene votos y (ii) para mejorar la respuesta.

Kommentieren Sie den Artikel

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein

Pruebas en línea