Por Anónimo (no verificado) , 29 Abril 2026

Dos extremos de un cable

El rendimiento de fetch y push depende de la eficiencia de negociación, tamaño de transferencia y cómputo del lado servidor. Cada uno tiene palancas, y las correctas difieren por tamaño de repo.

Por Anónimo (no verificado) , 29 Abril 2026

Por qué maintenance, no gc

git maintenance (Git 2.31+) es el reemplazo moderno orientado a tareas para gc --auto. Ejecuta tareas específicas (commit-graph, prefetch, incremental-repack, loose-objects, pack-refs, gc) en horarios afinados para cada una, en background, sin bloquear tus comandos interactivos.

Por Anónimo (no verificado) , 29 Abril 2026

Qué hace gc

git gc realiza mantenimiento: repacka objetos sueltos, poda los no alcanzables más allá de la ventana de expiración, empaqueta refs sueltas en packed-refs, expira reflogs, y escribe commit-graph y MIDX donde está configurado.

Por Anónimo (no verificado) , 29 Abril 2026

El costo del repack completo

git gc tradicional ejecuta git repack -ad, reescribiendo todos los objetos en un packfile. En un repo de varios gigabytes, son horas de CPU e IO. El repacking geométrico (Git 2.32+) lo evita manteniendo una serie de packs cuyos tamaños siguen una progresión geométrica — solo los más pequeños se mergean cada ciclo.

Por Anónimo (no verificado) , 29 Abril 2026

El problema de operaciones de conjunto

Operaciones como clone, fetch y gc necesitan calcular "¿qué objetos son alcanzables desde estos commits?" — un recorrido de grafo que toca cada objeto alcanzable. Los bitmaps de alcanzabilidad almacenan esta respuesta como bitmaps comprimidos, convirtiendo el recorrido en operaciones bitwise OR/AND.

Por Anónimo (no verificado) , 29 Abril 2026

El problema de muchos packs

Un repo con muchos packfiles debe buscar en cada uno para localizar un objeto — una búsqueda binaria por pack. Con docenas o cientos de packs (común en repos activos usando repack geométrico), este costo O(packs × log objetos) se acumula. El multi-pack-index (MIDX) consolida todos los índices de pack en una búsqueda binaria.

Por Anónimo (no verificado) , 29 Abril 2026

El problema del log restringido por ruta

git log -- path/to/file debe, en principio, recorrer cada commit, hacer diff contra su padre, y emitir los que tocaron path/to/file. En repos grandes esto está dominado por comparaciones de tree. Los filtros Bloom de rutas cambiadas (Git 2.27+) aceleran esto dramáticamente almacenando, para cada commit, un conjunto probabilístico de rutas que tocó.

Por Anónimo (no verificado) , 29 Abril 2026

El cuello de botella de alcanzabilidad

Muchas operaciones de Git necesitan responder "¿es el commit X alcanzable desde Y?" o "¿cuál es la base de merge?" Ingenuamente esto significa recorrer el grafo de commits desde lecturas crudas de objetos — lento en repos grandes. El archivo commit-graph precomputa punteros de padres, números de generación y (opcionalmente) filtros Bloom en un archivo lateral binario.

Dónde vive

Git antiguo: .git/objects/info/commit-graph. Git nuevo: .git/objects/info/commit-graphs/.

Por Anónimo (no verificado) , 29 Abril 2026

La facilidad Trace2

Trace2 (introducido en Git 2.22) es la facilidad de tracing estructurado integrada en Git. Emite eventos de inicio/fin de región, tracking de procesos hijos e información de tiempo en un esquema estable, adecuado tanto para inspección humana como análisis automatizado.

Por Anónimo (no verificado) , 29 Abril 2026

Herramientas lineales, repos exponenciales

Git fue originalmente afinado para el kernel de Linux — grande para 2005 pero pequeño para hoy. Los repos modernos pueden albergar millones de archivos, cientos de gigabytes de historia y decenas de miles de refs. Muchas operaciones de Git eran O(tamaño del árbol) u O(historia) por defecto, y a escala se volvieron visiblemente lentas.