Git LFS omitiendo el file, pero git comienza a empujarlo al repository

Tengo un file grande en mi repository Github que normalmente cargué con git lfs. Para una confirmación más reciente, tuve que cambiar el file, pero ahora al presionar, git lfs omite el file y el git normal intenta uploadlo. Esto, por supuesto, falla, porque excede el tamaño máximo de file de Github. Cuando corro

GIT_TRACE=1 git push

este es el resultado:

trace git-lfs: run_command: 'git' versión trace git-lfs: run_command: 'git' config -l trace git-lfs: tq: se ejecuta como queue por lotes, tamaño del lote de 100 trace git-lfs: run_command: ssh – git@github.com git-lfs-authenticate myRepo.git upload trace git-lfs: HTTP: POST https://lfs.github.com/myRepo/locks/verify trace git-lfs: HTTP: 200 trace git-lfs: HTTP: {"our": [], "theirs": [], "next_cursor": ""}

trace git-lfs: pre-push: refs / heads / master d7b0e4138403023433894f756d63bdadfabac125 refs / heads / master 683a30586bc68758230da6686fa902d4621b358a trace git-lfs: run_command: git rev-list –objects d7b0e4138403023433894f756d63bdadfabac125 –not –remotes = origen – trace git-lfs : run_command: git cat-file –batch trace git-lfs: tq: envío de lotes de tamaño 1 trace git-lfs: ssh cache: git@github.com git-lfs-authenticate myRepo.git upload trace git-lfs: api : files del lote 1 trace git-lfs: HTTP: POST https://lfs.github.com/myRepo/objects/batch trace git-lfs: HTTP: 200 trace git-lfs: HTTP: {"objects": [{" oid ":" 1e24fed72634c9217ce7856d11ee204d38eb154fc90572a8ef047007f2211a6c "," size ": 246116656}]} trace git-lfs: tq: adaptador de transferencia inicial" básico "Git LFS: (0 de 0 files, 1 omitido) 0 B / 0 B, 234.72 MB omitido
17: 22: 37.083227 run-command.c: 343 trace: run_command: 'pack-objects' '–all-progress-implied' '–revs' '–stdout' '–thin' '–delta- base-offset '' –progress '17: 22: 37.084316 exec_cmd.c: 128
trace: exec: 'git' 'pack-objects' '–todo-progresivo-implicado' '–revs' '–stdout' '–thin' '–delta-base-offset' '–progreso' 17: 22: 37.088704 git.c: 348 trace: built-in: git 'pack-objects' '–todo-progresivo-implicado' '–revs' '–stdout' '–thin' '–delta -base-offset '' –progress 'Contando objects: 109, hecho. Compresión Delta utilizando hasta 4 hilos.

Comprimir objects: 100% (106/106), hecho. Escritura de objects: 100% (109/109), 73.55 MiB | 1.81 MiB / s, hecho. Total 109 (delta 74), reutilizado 0 (delta 0) remoto: Resolución de deltas: 100% (74/74), completado con 53 objects locales. remoto: error: GH001: files grandes detectados. Es posible que desee probar Git Large File Storage – https://git-lfs.github.com . remote: error: Trace: e87aee9bcda79c0a788ae345112c9d37 remote: error: Consulte http://git.io/iEPt8g para get más información. remoto: error: El file src / ios / sdk / myLib.framework / Framework es 234.72 MB; esto excede el límite de tamaño de file de GitHub de 100.00 MB a git@github.com: myRepo.git! Error de [control remoto rechazado] -> error maestro (error previo al envío de recepción): error al enviar algunas references a 'git@github.com: myRepo.git'

Parece que el filter clean lfs no se aplicó al agregar la nueva versión del file al índice. Si el nombre del file no cambió, entonces eso probablemente significa que no hay un file .gitattributes que asocie esa ruta con LFS. (O nunca hubo uno y de alguna manera ejecutó el filter limpio manualmente cuando agregó por primera vez la versión anterior del file, o hubo uno pero no se comprometió, o desde entonces se ha eliminado o modificado de una manera que ya no coincide con el file; etc …)

Y para aclarar: si el nombre del file cambió, probablemente haya cambiado a algo que no concuerde con ninguna ruta en el file .gitattributes. Por lo tanto, necesitaría actualizar .gitattributes para que coincida con el nuevo nombre de file.

Una vez que un file se organiza con el seguimiento de LFS, lo que git ve (en el índice y en la database) es el file de puntero LFS. Por lo tanto, aunque se haya eliminado el file de attributes, no provocaría que el file grande se cargue en la database del repository. Pero si vuelve a agregar el file (como lo haría después de modificarlo) y los attributes no están configurados en ese momento, entonces todo el file se clasifica en lugar de un file de puntero.

Creo que lo que LFS omite en su rastro anterior es la versión anterior del file, porque el server ya tiene eso. Esto es normal.

Pero el compromiso que estás tratando de impulsar no es bueno; tiene el file completo irrevocablemente embedded en él. Necesita modificar (o volver a establecer la base, o volver a escribir) cada confirmación que tenga el file completo en ella. Afortunadamente, dado que esto impide compartir las confirmaciones, debe poder reescribirlas de forma segura sin preocuparse de que alguien más se encuentre en una situación de "rebase ascendente".

Entonces para resumir:

Asegúrese de tener un file .gitattributes que asigne los attributes LFS a una ruta que coincida con el file grande. Debe agregar este file .gitattributes al índice.

Elimine y vuelva a indexar la nueva versión del file grande.

 git rm --cached path/to/big/file git add path/to/big/file 

Si .gitattributes está configurado correctamente, el add pasará por el filter de limpieza LFS esta vez; se agregará un file de puntero al índice y se creará un nuevo object LFS.

 git commit --amend 

para replace el compromiso que tiene el BLOB grande embedded en él con uno nuevo que usa LFS.

Ahora intenta empujar. Si aún falla, eso significa que probablemente haya otras confirmaciones que deba corregir, y entonces las cosas podrían involucrarse más.