Git 2.56 incorpora un staging de conflictos más seguro y acelera el mantenimiento de repositorios

Git 2.56.0 ya está disponible con cambios orientados a hacer más segura la resolución de conflictos y más escalable el mantenimiento de repositorios. Esta versión añade un modo de staging específico para conflictos resueltos, acorta algunas búsquedas de merge-base y elimina dos restricciones que limitaban el uso de repacks path-walk, orientados a ahorrar espacio, en servidores de repositorios.

Staging de conflictos más seguro

El nuevo modo git add --resolved incorpora al staging únicamente las rutas que siguen marcadas como no fusionadas. Antes de modificar el índice, comprueba si los archivos normales seleccionados conservan marcadores de conflicto; si encuentra alguno, no incorpora ninguno de esos archivos. Los cambios rastreados que no están relacionados permanecen intactos, lo que reduce el riesgo de incluir accidentalmente trabajo local mediante comandos más amplios como git add -u o git add -A.

Los desarrolladores pueden proporcionar un pathspec para limitar la operación. Las eliminaciones resueltas y los conflictos binarios también pueden incorporarse, porque no contienen marcadores textuales. El nuevo modo no se puede combinar con las opciones update o all, que tienen un alcance más amplio.

Salida anticipada en merge-base

Git ahora registra si todavía quedan commits exclusivos de alguno de los dos lados en la cola de recorrido de merge-base. Cuando uno de esos lados exclusivos se agota, la búsqueda puede terminar, porque no puede aparecer otro punto común, y mantiene al mismo tiempo la compatibilidad con historiales que tienen varios merge-bases válidos.

GitHub informa de mejoras considerables en los repositorios evaluados. En un monorepo, una operación pasó de 0,68 segundos a 0,01; en evaluaciones de producción, muchas operaciones fueron unas 70 veces más rápidas en otro monorepo grande y la mejora media fue de aproximadamente 20 veces en uno distinto. En un caso basado en el kernel de Linux, los pasos de recorrido bajaron de 167.441 a 3.887.

Repacks más pequeños en servidores

El repacking path-walk agrupa los objetos según su ubicación dentro del árbol para encontrar relaciones delta más eficientes. En la prueba de GitHub con Fluent UI, generó un pack de 164,4 MB, frente a los 558,5 MB de un repack normal basado en bitmaps: una reducción cercana al 71 %. Git 2.56 hace que este enfoque sea compatible con los reachability bitmaps y los delta islands, eliminando dos obstáculos para su adopción en hosts de repositorios.

La función sigue siendo opcional. Los operadores de servidores pueden evaluar sus ventajas de almacenamiento sin renunciar a la enumeración de objetos asistida por bitmaps ni a las reglas de aislamiento de los delta islands, aunque Git no activa el repacking path-walk de forma predeterminada.

Más cambios en los flujos de trabajo

Entre las demás novedades se incluyen el comando experimental git history drop, la eliminación masiva de ramas fusionadas, opciones de limpieza automática para git bisect run y un modo --linearize para el comando experimental git replay. Los clones parciales también pueden descartar manualmente blobs grandes y recuperables mediante un repack filtrado, aunque el mecanismo solo admite por ahora filtros blob:limit y requiere un promisor remote.

Git 2.56 también mejora el seguimiento de renombrados de git log --follow en historiales no lineales y corrige varios problemas de escalabilidad. Entre los ejemplos comunicados figuran una mejora de unos ocho minutos a 0,07 segundos en un diff limitado por ruta sobre un checkout de Chromium y una reducción de aproximadamente 13 segundos a 0,2 segundos en las pruebas de tombstones de reftable.

Ilustración editorial generada con IA; no es una fotografía documental.

Fuente: Highlights from Git 2.56