Al presionar la label en git, se produce un error: el tamaño del file supera el límite

Estoy trabajando con un repository remoto que tiene algunos files bastante grandes. Sin embargo, puedo comprometerme, empujar y tirar sin ningún problema.

Sin embargo, cuando bash agregar una label anotada

git tag -a v0.0.1 -m 'First tag, to a very beta version.' 

y luego empujarlo al repository, obtengo:

 $ git push origin v0.0.1 Counting objects: 1, done. Writing objects: 100% (1/1), 181 bytes | 0 bytes/s, done. Total 1 (delta 0), reused 0 (delta 0) remote: Size of file '...' in commit ... is over limit (20000000 bytes) ... remote: Size of file '...' in commit ... is over limit (20000000 bytes) remote: Size of file '...' in commit ... is over limit (20000000 bytes) To https://....git ! [remote rejected] v0.0.1 -> v0.0.1 (pre-receive hook declined) error: failed to push some refs to 'https://....git' 

Algo más de información:

  1. La twig en la que estoy trabajando ya no tiene estos files grandes. Estos files grandes todavía están en el historial, y en otra twig, pero no en confirmaciones recientes.
  2. El repository local es un clon de una sola twig, con –depth = 5, por lo que los files grandes que dan error no deberían estar en absoluto en este repository local.

Gracias por tu ayuda.

Hay pistas interesantes en la salida que nos dicen que son los ganchos del repository remoto los que se están portando mal. (Lo que a su vez significa que, a less que tenga acceso directo a ese sistema y pueda hacer un alboroto con los ganchos de allí, no puede arreglarlo usted mismo. Por supuesto, si tiene acceso directo a ese sistema, puede simplemente configurar la label allí en primer lugar).

Comencemos con una breve reseña. Esta:

remote: Size of file '...' in commit ... is over limit (20000000 bytes)

viene de un gancho de pre-recepción (o potencialmente, un gancho de actualización, pero vemos pre-receive en la línea de remote rejected ). Estos ganchos suelen estar en su lugar para evitar que las personas agreguen commits accidentalmente con binarys grandes o files de bases de datos o lo que sea. El código en el gancho que encuentra estos hace un recorrido de gráfico usando la actualización de reference propuesta (o creación), y en este caso, está tomando claramente la operación de creación de label y atravesando un grupo de confirmaciones existentes, algunas de las cuales tienen files grandes, por lo tanto escupiendo los posts de error y rechazando el empuje.

Mencionas eso

La twig en la que estoy trabajando ya no tiene estos files grandes. Estos files grandes todavía están en el historial, y en otra twig, pero no en confirmaciones recientes.

Si bien la twig no es realmente interesante, está presionando una label, no una twig, por lo que la actualización de reference que está recibiendo el control remoto es refs/tags/v0.0.1 Ahora sabemos que hay files grandes en el repository (en el control remoto, aunque no local debido a la profundidad limitada del clon).

La otra key key aquí es esta:

 Counting objects: 1, done. Writing objects: 100% (1/1), 181 bytes | 0 bytes/s, done. Total 1 (delta 0), reused 0 (delta 0) 

Su inserción envía un (1) object que tiene 181 bytes de longitud y no está comprimido en delta contra ningún otro object. Este es, por supuesto, el object de label anotado, ¡y claramente no hay files de 20 megabytes aquí! Por lo tanto, el control remoto debe encontrarlos como consecuencia de seguir el objective del object de label (que sería el HEAD en el momento en que creó la label: este compromiso ya debe existir en el control remoto ya que su inserción no lo está enviando), y -correctamente concluyendo que algunos commit (s) que ya están en el repository remoto son por lo tanto nuevos y deberían eliminarse por error.