Git 2.55: fsmonitor para Linux, MIDX incremental y hooks paralelos

El proyecto Git liberó la versión 2.55, con features y bug fixes de más de 100 contribuidores, 33 de ellos nuevos. GitHub publicó su repaso habitual con los cambios más interesantes desde la 2.54, y salen a la luz un par de mejoras estructurales que van a marcar la forma de operar repos grandes.

Repack incremental con multi-pack indexes

Git guarda el contenido del repositorio como objetos individuales (commits, trees y blobs). Esos objetos suelen vivir dentro de packfiles, colecciones comprimidas con un pack index que le permite a Git localizar cualquier objeto rápido. Un repositorio grande no tiene un solo packfile: fetches, pushes, mantenimiento y repacks van dejando muchos packs por el camino.

Un multi-pack index (MIDX) le da a Git un único índice sobre muchos packs. Es especialmente útil en repositorios grandes y es uno de los ladrillos de la estrategia de mantenimiento de GitHub. Desde Git 2.47 existe el formato incremental de MIDX: en vez de un archivo único que cubra todos los packs, el MIDX se guarda como una cadena de capas, donde cada capa cubre una colección de packs y el archivo chain registra el orden.

Git 2.55 le enseña a git repack a escribir esas cadenas directo:

$ git repack --write-midx=incremental

Sin más opciones, el modo es append-only. Pero una cadena append-only no puede crecer sin límite, así que 2.55 permite combinar el modo incremental con geometric repacking:

$ git repack --write-midx=incremental --geometric=2 -d

Cada repack escribe una nueva capa tip, luego decide si las capas adyacentes deben ser compactadas. La regla por defecto está controlada por repack.midxSplitFactor: si el conteo acumulado de objetos en las capas nuevas crece lo suficiente respecto de la siguiente capa más vieja, Git las fusiona en una capa reemplazo; si no, las capas viejas quedan intactas.

El compromiso es entre dos extremos. Un MIDX de archivo único minimiza la complejidad de lookup pero puede requerir reescrituras enormes durante el mantenimiento. Un incremental puramente append-only minimiza cada escritura pero deja crecer la cadena sin cota. El repack geometrico incremental mantiene el número de capas logarítmico en el total de objetos.

git history fixup: editar commits anteriores sin pelear con rebase

Cualquiera que haya pulido una serie de commits antes de mandarla a revisión conoce la situación: te das cuenta de que un cambio en tu working tree en realidad pertenece a un commit anterior, no al tip de la rama.

La forma común hoy es crear un fixup commit y hacer autosquash:

$ git commit --fixup=<commit>
$ git rebase --autosquash <commit>^

Funciona, pero fuerza a explicitar el mecanismo. Git 2.55 se apoya en el subcomando experimental git history (introducido en 2.54) y le agrega un nuevo fixup. Aplica los cambios que están en el índice a un commit anterior:

$ git history fixup <commit>

El comando toma la modificación stageada, la mete en el commit target y reproduce los commits descendientes sobre la nueva historia. Es todavía experimental y deliberadamente conservador: aborta ante conflicto en vez de dejar el repo en estado inconsistente.

Hooks paralelos: por fin en configuración

Git 2.54 permitía definir config-based hooks en la propia configuración de Git en vez de archivos ejecutables en $GIT_DIR/hooks. La versión 2.55 extiende ese trabajo permitiendo que los hooks compatibles corran en paralelo. Un proyecto puede tener hooks pre-commit independientes para linting y unit tests; si ambos declaran hook.<name>.parallel = true, Git los corre al mismo tiempo. El número de jobs concurrentes se controla con hook.jobs, con hook.<event>.jobs por evento o con -j en la línea de comandos.

Los hooks que necesitan estado compartido, como los commit-msg u otros que inspeccionan índice o working tree, siguen corriendo en serie.

fsmonitor built-in aterriza en Linux vía inotify

Si alguna vez corriste git status y te comiste una pausa larga, probablemente conoces el filesystem monitor incorporado de Git. Con core.fsmonitor habilitado, comandos como git status preguntan a un demonio de larga duración cuáles rutas cambiaron en vez de escanear todo el working tree.

Hasta ahora ese demonio built-in existía sólo en macOS y Windows. Git 2.55 agrega soporte en Linux vía inotify. Corre sin privilegios elevados, pero necesita un watch por directorio, así que los repos muy grandes pueden requerir subir fs.inotify.max_user_watches. Al igual que en otras plataformas, el demonio se queda quieto ante repos en volúmenes de red (siguen siendo opt-in).

Reachability bitmaps: de 612 a 294 segundos

Los reachability bitmaps son uno de los trucos que Git usa para responder preguntas como "¿qué objetos son alcanzables desde este commit?" sin recorrer todo el object graph. Aceleran los traversals pero hay que construirlos y actualizarlos durante tareas de mantenimiento como git repack --write-midx-bitmaps.

Git 2.55 hace la generación más rápida evitando recursión innecesaria en trees, reutilizando bitmaps ya seleccionados, cacheando posiciones de objetos y ordenando los bitmaps antes de hacerles XOR. En benchmarks de la serie de parches, esas mejoras generales redujeron el tiempo de generación en un repositorio grande de 612 a 294 segundos, o sea a menos de la mitad. La misma serie mejora también los pseudo-merge bitmaps.

¿Qué implica para equipos en Chile?

Para equipos DevOps que mantienen monorepos en la región (típicamente sobre GitLab self-hosted o Gitea), los cambios de 2.55 son directos: fsmonitor en Linux acorta cada git status a decimas de segundo, el MIDX incremental deja de bloquear runners de CI durante el mantenimiento y los hooks paralelos aceleran los ciclos pre-commit en proyectos con múltiples validadores.