Git 2.56 añade git add --resolved y repacks hasta un 71% más pequeños
La nueva versión del sistema de control de versiones llega con 104 contribuyentes, un modo seguro para escenificar conflictos y una poda del cálculo de merge bases hasta 70 veces más rápida.
El proyecto Git ha publicado la versión 2.56.0, con cambios de más de 104 contribuyentes, 39 de ellos nuevos. Hay tres cosas que le importan a quien mantiene repositorios grandes: un modo nuevo de git add, una poda mucho más agresiva al calcular merge bases y repacks path-walk que ya conviven con los bitmaps de alcanzabilidad y las islas delta.
Un git add --resolved que no escenifica de más
Resolver un conflicto tiene dos partes: dejar el árbol de trabajo como quieres y escenificar esas rutas para decirle a Git que ya está resuelto. El segundo paso es donde se mete la pata. git add -u toca toda ruta rastreada que esté modificada, incluidas las que no tienen nada que ver con el merge, y puede escenificar un archivo que todavía lleva marcadores de conflicto.
El modo nuevo mira solo las rutas que siguen sin fusionar en el índice. Antes de tocar nada, revisa los archivos regulares no fusionados en busca de marcadores; si encuentra uno, avisa de qué rutas son y deja el índice intacto. Acepta un pathspec para acotar la selección, y dentro de ella mantiene la regla de todo o nada: un solo archivo con marcadores y no se escenifica ninguno. Los borrados resueltos y los conflictos binarios no tienen marcadores de texto, así que se escenifican con normalidad. No se combina con -u ni con -A, y se salta los archivos rastreados que nunca estuvieron en conflicto. Es un carril más estrecho, y a propósito.
Parar antes cuando ya no caben más merge bases
Merges, diffs de tres puntos, comprobaciones de mergeabilidad y rangos de revisión necesitan el mejor ancestro común de dos commits. Git lo busca caminando hacia atrás desde ambas puntas; imagina que pinta de azul lo alcanzable desde un lado y de rojo lo del otro, y cualquier commit que reciba los dos colores es candidato. Con merges cruzados puede haber varios candidatos y ninguno ser ancestro de otro, así que hay que seguir hasta saber que están todos. El problema era que la regla antigua seguía procesando una cola larga de historia ya común cuando encontrar otro candidato ya era imposible.
La versión 2.56 cuenta cuántos commits en cola siguen pintados en exclusiva por cada lado. Cuando un lado exclusivo se agota, no puede aparecer ningún punto de encuentro nuevo, y Git corta sin perder merge bases. En un monorepo real el recorrido pasó de 0,68 segundos a 0,01. En evaluaciones sobre dos monorepos grandes aparecieron casos unas 70 veces más rápidos en uno y una mejora media de unas 20 veces en el otro. La serie también arregla un caso del kernel de Linux que arrastraba lustre: con el commit-graph v2 por defecto, git merge-base --all v4.8 v4.9 baja de 167.441 pasos y 0,29 segundos a 3.887 pasos y 0,01 segundos.
Repacks path-walk compatibles con bitmaps e islas delta
Al reempaquetar, Git busca objetos parecidos para guardarlos como deltas. El search tradicional agrupa candidatos por hash de nombre; el path-walk los recorre por su posición en el árbol, junta versiones de la misma ruta y encuentra mejores relaciones. El ahorro es serio: en un benchmark con un clon reciente de microsoft/fluentui, forzando el recálculo de deltas, un repack normal con bitmaps produjo un pack de 558,5 MB y el mismo repack con --path-walk se quedó en 164,4 MB, un 71% menos.
El problema era dónde se podía desplegar. Los hosts usan bitmaps de alcanzabilidad para responder consultas de enumeración de objetos, y algunos usan islas delta para que los objetos de un grupo de refs no dependan de otros disponibles solo en otro grupo. El path-walk era incompatible con ambos. La 2.56 levanta las dos restricciones: un repack path-walk puede seleccionar commits para un bitmap nuevo, y las invocaciones posteriores de git pack-objects pueden reutilizar un bitmap existente, cayendo al path walk solo cuando haga falta. También propaga la pertenencia a islas por commits y árboles antes de elegir bases delta.
Las dos últimas mejoras apuntan al mismo sitio: hosts de repositorio y monorepos con historia larga. El cálculo de merge bases se ejecuta en cada diff de pull request y en cada comprobación de mergeabilidad, así que recortar el recorrido se nota en CPU. Y el repack path-walk solo era desplegable donde no hubiera bitmaps ni islas de por medio. Queda por ver cómo se comporta con muchas refs e islas delta grandes, que es justo donde el bookkeeping nuevo tiene más trabajo.