Diagnosticar corrupción

Los repositorios se corrompen por pérdida de energía, fallo de disco, sync de red parcial, o herramientas no-Git con bugs tocando .git. Los síntomas van de "fatal: bad object" a contenido erróneo entregado silenciosamente. El diagnóstico empieza con fsck:

La configuración todo-en-uno

Juntando las piezas: esta es una configuración única que aplica el stack moderno de rendimiento de Git. Colócala en .git/config en un clone fresco, ejecuta las tareas únicas, y tendrás la configuración recomendada para repos con cientos de miles de archivos e historia activa.

Conocer tu peso

Antes de optimizar, mide. Git incluye git count-objects para estadísticas básicas; git-sizer de terceros de GitHub da un análisis más profundo con umbrales de problema.

fast-export y fast-import

git fast-export serializa un repositorio a un stream de comandos; git fast-import reconstruye un repositorio a partir de uno. Juntos forman el protocolo de intercambio de datos de Git — usado por importadores (cvs2git, hg-fast-export) y por herramientas como git filter-repo internamente.

El problema cross-fork

Los servidores Forge (GitHub, GitLab) hospedan muchos forks de un repo juntos. Ingenuamente, un solo packfile comprime delta entre todos los forks — eficiente en disco, pero ineficiente al servir un solo fork. Las islas delta restringen las cadenas delta para que las cadenas de cada fork permanezcan dentro de su propio conjunto de objetos.

La capa de transporte

El protocolo de cable de Git históricamente intercala mensajes cliente y servidor sobre una conexión con estado. stateless-connect (introducido para protocolo v2 sobre HTTP) desacopla las solicitudes para que cada una sea ruteable independientemente.

Flujos sin estado

GIT_TRACE_PACKET=1 GIT_TRACE_CURL=1 \
  git -c protocol.version=2 fetch origin 2>&1 | head -50

Beneficios HTTP/2

El multiplexing HTTP/2 permite que múltiples solicitudes sin estado compartan una conexión.

Por qué v2

El protocolo v0/v1 enviaba la publicidad completa de refs del servidor al inicio de cada fetch — un payload proporcional al número de refs. En repos con decenas de miles de refs, esto dominaba el tiempo de transferencia. El protocolo v2 (default en Git 2.26+) permite al cliente solicitar refs específicas por nombre.

El compromiso shallow

Un clone shallow (--depth=N) descarga solo los últimos N commits. Más rápido, más pequeño, pero con advertencias: muchas operaciones dependientes de la historia se vuelven imposibles o incorrectas. CI es el hogar natural para clones shallow, pero solo cuando entiendes los límites.

Dos victorias de paralelismo

Dos configuraciones desbloquean speedups significativos para operaciones cotidianas. core.preloadIndex paraleliza las llamadas lstat que git status hace; el checkout paralelo (Git 2.32+) paraleliza las escrituras de archivos durante git checkout, git switch y git restore.

Presupuestos de repack

Cuando Git computa deltas durante repack, considera una ventana de objetos base candidatos por target. Ventanas más grandes producen packs más pequeños pero usan más memoria y CPU. El ajuste es esencial para repos enormes y runners de build con restricciones por igual.