Git pull: el filtro de manchas lfs falló

⏰ 7 minutos de lectura

avatar de usuario
Jack

Estoy intentando extraer código en nuestro servidor desde Github (git pull origin master).

Esto funcionó antes. Sin embargo, ahora recibo el siguiente error:

$ git pull origin master
From github.com:org-name/repo-name
 * branch              master     -> FETCH_HEAD
Updating 8024663e..e458e5c1
fatal: path/to/file.msi: smudge filter lfs failed

Ejecuté el mismo comando con GIT_TRACE=1:

$ GIT_TRACE=1 git pull origin master
19:25:26.331064 git.c:371               trace: built-in: git 'pull' 'origin' 'master'
19:25:26.333947 run-command.c:350       trace: run_command: 'fetch' '--update-head-ok' 'origin' 'master'
19:25:26.334661 exec_cmd.c:116          trace: exec: 'git' 'fetch' '--update-head-ok' 'origin' 'master'
19:25:26.337625 git.c:371               trace: built-in: git 'fetch' '--update-head-ok' 'origin' 'master'
19:25:26.344457 run-command.c:350       trace: run_command: 'ssh' 'git@github.com' 'git-upload-pack '\''org-name/repo-name.git'\'''
19:25:26.925565 run-command.c:350       trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet'
19:25:26.937016 run-command.c:350       trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet'
19:25:26.937833 exec_cmd.c:116          trace: exec: 'git' 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet'
19:25:26.941292 git.c:371               trace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all' '--quiet'
From github.com:org-name/repo-name
 * branch              master     -> FETCH_HEAD
19:25:26.994717 run-command.c:1130      run_processes_parallel: preparing to run up to 1 tasks
19:25:26.994880 run-command.c:1162      run_processes_parallel: done
19:25:26.995780 run-command.c:350       trace: run_command: 'gc' '--auto'
19:25:26.996735 exec_cmd.c:116          trace: exec: 'git' 'gc' '--auto'
19:25:27.000596 git.c:371               trace: built-in: git 'gc' '--auto'
19:25:27.002716 run-command.c:350       trace: run_command: 'merge' 'FETCH_HEAD'
19:25:27.003445 exec_cmd.c:116          trace: exec: 'git' 'merge' 'FETCH_HEAD'
19:25:27.006078 git.c:371               trace: built-in: git 'merge' 'FETCH_HEAD'
Updating 8024663e..e458e5c1
19:25:27.420945 run-command.c:350       trace: run_command: 'git-lfs filter-process'
19:25:27.470865 run-command.c:209       trace: exec: '/bin/sh' '-c' 'git-lfs filter-process' 'git-lfs filter-process'
trace git-lfs: run_command: 'git' version
trace git-lfs: run_command: 'git' config -l
trace git-lfs: Initialize filter-process
trace git-lfs: Read filter-process request.
trace git-lfs: Read filter-process request.
fatal: path/to/file.msi: smudge filter lfs failed
19:25:27.998635 run-command.c:42        trace: run_command: running exit handler for pid 18022

Verifiqué que mis credenciales ssh son correctas:

$ ssh -T git@github.com
Hi user-name! You've successfully authenticated, but GitHub does not provide shell access.

Y, de hecho, sé que las credenciales están bien, porque el pull derribará el .gitattributes archivo (junto con otros pequeños cambios de archivos que he hecho):

 file.msi filter=lfs diff=lfs merge=lfs -text

Verifiqué que Git LFS parece estar configurado correctamente:

$ git config -l
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
...

encontré esto Problema de Githuby probé los tres pasos:

$ echo "protocol=https\nhost=github.com" | git credential fill
$ echo "protocol=https\nhost=github.com" | git credential fill | git credential reject
$ echo "protocol=https\nhost=github.com" | git credential fill | git credential approve

El primer paso me pidió mi nombre de usuario. Entonces, como dice, no parece que Git LFS esté almacenando nada en caché.

No tengo mucha experiencia con Git LFS y, francamente, no tengo ideas sobre cómo abordar este problema.

Hay dos acciones que tomé recientemente que podrían haber roto algo:

  1. Eliminé a un usuario de nuestro repositorio. La clave ssh del servidor pertenecía al usuario. Agregamos una clave de implementación, pero leí que Git LFS no admitía claves de implementación (aunque, parece que el soporte se agregó recientemente). Entonces, cambiamos a una clave de usuario. Ambas llaves fueron confirmadas con el ssh -T git@github.com prueba. Aún así, ¿quizás haya un problema de autenticación?
  2. Bajé el repositorio a un servidor sin Git LFS. No me di cuenta en ese momento, pero los archivos se transfirieron bien al servidor de destino. Sin embargo, ¿tal vez esto rompió algo en el repositorio?

Cualquier ayuda que pueda prestar sería muy apreciada.

PD: lo siento si mi anonimización crea confusión. Reemplacé nuestra dirección IP real con X.X.X.X; el nombre de nuestra organización con org-name; nuestro nombre de repositorio con repo-name; nuestro usuario de Github con user-name; el nombre del archivo con file.msi; y, algunas cosas más.

EDITAR 16/05/17: Se agregó lenguaje para dejar en claro que solía funcionar… y que lo rompí.

avatar de usuario
nieto

En mi caso, el repositorio autenticado por SSH se actualizó para usar LFS de otro cliente y, por mi parte, Git-LFS no conocía la URL remota de SSH. Lo que hice para solucionarlo fue lo siguiente:

Copie la URL configurada en remote.origin.url (insertar URL para origin) para lfs.url (la URL que utiliza LFS):

$ git config lfs.url $(git config remote.origin.url)

(Si su control remoto no se llama origin luego cambie a su nombre remoto).

Entonces corre

$ git config lfs.url

para mostrar la URL y confirmar que efectivamente contiene una URL SSH y no una URL HTTP/HTTPS.

Entonces tú puedes

$ git pull

Hecho.

Si la cagaste antes y master y orgin/master han divergido de alguna manera como fue mi caso, entonces es posible que deba git checkout -fB master origin/master (esto no pregunta y sobrescribe la versión local de la rama maestraentonces ten cuidado y ejecuta con cuidado!).

Ver también: https://github.com/git-lfs/git-lfs/issues/2661#issuecomment-335903332

  • Gracias por la respuesta @grandchild. Terminamos tomando una o dos horas para mover los archivos binarios al servidor usando scpy estamos trabajando en la implementación de un sistema de servidor de archivos como S3 en lugar de Git LFS. Continuaré y marcaré esto como la respuesta, ya que resolvió un problema similar para usted. Le di la vuelta jaja. ¡Gracias por la respuesta!

    – Jack

    22 de febrero de 2018 a las 17:31

  • ¡Eso fue todo! También tenga en cuenta: si está utilizando un control remoto diferente, ajuste git config remote.origin.url para git config remote.<MY_OTHER_REMOTE>.url.

    – Tomasz Gandor

    17 de mayo de 2018 a las 9:26

  • Entonces, ¿entiendo correctamente que GIT LFS no se preocupa por la URL remota y en su lugar usa la URL remota del repositorio en el que se configuró? ¿Es esto un error o una característica de GIT LFS?

    – Florián Invierno

    10 oct 2019 a las 13:13

  • @FlorianWinter Creo que es más que Git LFS simplemente no tiene una URL al extraer, si el repositorio se clonó cuando el repositorio no tenía habilitado LFS. Si clona un repositorio con LFS ya habilitado, me imagino que la configuración explicada anteriormente se establecerá de la misma manera, solo automáticamente.

    – nieto

    10 oct 2019 a las 13:42

  • Esto me sucedió con un repositorio recién clonado. Alguien más configuró GIT LFS mucho antes de que yo lo clonara. @grandchild Sin embargo, investigaré más por mi cuenta si aún puedo reproducirlo / tengo tiempo para hacerlo. Gracias.

    – Florián Invierno

    10 oct 2019 a las 13:53

En mi caso, tengo que agregar un paso más después de seguir las instrucciones proporcionadas por la respuesta de @grandchild. Como explicó @grandchild, mi repositorio git remoto se cambió para usar el protocolo ssh del https original recientemente. En mi configuración de git, la configuración de git “http.sslverify” no se configuró originalmente. Creo que el valor predeterminado es verdadero si falta. Causó el error “filtro de manchas lfs falló”. Una vez que lo configuré en falso

$ git config http.sslverify falso

Funciona sin errores.

  • Esto omite la verificación del certificado SSL, lo cual no es una buena idea en general. Debe investigar por qué falla la verificación del certificado en primer lugar. Cuando trabaje con certificados autofirmados (que probablemente sea la única excusa válida a corto plazo para deshabilitar la verificación), eche un vistazo a git-scm.com/docs/git-config#EJEMPLOS (hacia el final de esa sección). Puede deshabilitar la verificación de una sola URL.

    – nieto

    10 de febrero de 2021 a las 23:18

  • @grandchild Como mencioné en mi comentario, la falla fue causada por un cambio reciente en el protocolo de conexión, de https a ssh, en nuestro repositorio remoto. El cambio falló en http.sslverify ya que ya no es compatible con nuestro repositorio remoto.

    -Feng Yang

    12 de febrero de 2021 a las 20:20

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad