Descripción: Qué significa el error de espacio insuficiente, por qué un repositorio puede crecer tanto y cómo evitar descargarlo entero para cambiar un archivo.
La tarea parecía pequeña: corregir unas líneas. Pero aparece el mensaje “Not enough disk space to clone the repository”.
¿Se rompió el código? No. Significa que el entorno donde se intenta copiar el repositorio no dispone de suficiente espacio. No afirma que los archivos de GitHub se hayan borrado.
En un caso real, la API de GitHub indicaba un tamaño aproximado de 9 GB. Pediste una hoja de papel y llegó un camión con toda la papelería. Incluido el mostrador.
Lo que el aviso confirma
La operación de copia se encontró con un problema de almacenamiento. Por sí solo, el mensaje no revela cuánto espacio libre quedaba, cuánto se había descargado ni si el peso procede de los archivos actuales o del historial.
Los 9 GB son una cifra redondeada del tamaño informado por la API; no son una medición exacta de la copia que falló. Los objetos descargados, los archivos descomprimidos y el espacio temporal pueden ocupar cantidades distintas.
De dónde sale tanto peso
Git conserva versiones anteriores, no solo los archivos visibles hoy. Imágenes grandes, copias de seguridad y resultados generados que se añadieron en el pasado pueden seguir aumentando el historial. También puede ser grande el directorio actual si se acumulan artículos, traducciones y recursos.
Hay que medir archivos actuales e historial antes de atribuir el problema a uno de ellos.
GitHub recomienda mantener los repositorios manejables e incluye un máximo recomendado de 10 GB para el tamaño en disco del directorio .git. No es un interruptor que bloquee automáticamente todos los clones al alcanzar esa cifra, ni tiene por qué coincidir con el dato de la API.
La solución: no traerlo todo
Un entorno nuevo puede ayudar si el anterior estaba lleno de archivos temporales. Si el repositorio es grande por sí mismo, el problema puede repetirse.
Para leer o modificar un archivo concreto, la API de archivos de GitHub puede evitar la clonación completa, siempre que se tengan los permisos adecuados.
Si necesitas Git, prueba a limitar el historial y los archivos iniciales:
git clone --depth=1 --filter=blob:none --sparse REPOSITORY_URL
Esta combinación descarga menos historial, retrasa la descarga del contenido de archivos y reduce lo que se despliega al principio. No garantiza el éxito en todos los entornos y limita ciertas tareas que necesitan el historial completo.
El atajo que puede salir caro
No borres ni reescribas el historial por impulso. Podrías afectar a otros colaboradores, referencias antiguas y procesos automáticos. Primero comprueba el espacio libre, localiza los archivos grandes actuales y los objetos históricos, y prepara copias de seguridad si vas a hacer una limpieza destructiva.
La auténtica avería
El encargo era editar unas líneas. El plan de transporte era mover un almacén de 9 GB.
¿Por qué trasladar todo el repositorio cada vez que solo necesitas un archivo? Antes de comprar un disco mayor, revisa cómo estás transportando los datos.
Fuentes: límites recomendados por GitHub, archivos grandes, documentación de Git clone.
