Después de dos meses de desarrollo, se presenta la versión 2.51 del sistema de gestión distribuido de texto fuente Git. Git se caracteriza por su alta rendimiento y proporciona herramientas para el desarrollo no lineal, basado en la ramificación y mezcla de ramas. Para garantizar la integridad de la historia y la resistencia a los cambios retroactivos, se utiliza el hash implícito de toda la historia anterior en cada commit, así como la verificación mediante firmas digitales de los desarrolladores para etiquetas y commits individuales. El código de Git se distribuye bajo la licencia GPLv2+.
Comparado con la versión anterior, en la nueva versión se han aceptado 506 cambios, preparados con la participación de 91 desarrolladores (21 de los cuales participaron en el desarrollo de Git por primera vez). Las principales novedades (1, 2, 3):
- Se ha mejorado el rendimiento de los comandos «git push» y «git fetch» en repositorios con un gran número de referencias. Esta mejora se ha logrado mediante la actualización de referencias en modo por lotes, donde se procesan varias referencias en una sola transacción, en lugar de crear una transacción separada para actualizar cada referencia. Esta optimización ha aumentado considerablemente la velocidad del backend «reftable», que ahora supera en rendimiento al backend «files». Por ejemplo, en un repositorio de prueba con 10,000 referencias, el rendimiento de «git fetch» al usar el backend «reftable» aumentó 22 veces, mientras que al usar el backend «files» aumentó 1.25 veces. Para «git push», el crecimiento fue de 18 y 1.21 veces, respectivamente.
- Se ha propuesto un nuevo método para empaquetar en archivos pack partes del repositorio que no están relacionadas con el seguimiento de objetos inalcanzables, a los que no hacen referencia ramas o etiquetas. La información sobre objetos inalcanzables se almacena en archivos pack separados («cruft packs»), lo que hacía necesario reflejarlos en índices multi-pack MIDX (índice de múltiples paquetes) para abarcar objetos que inicialmente eran inalcanzables y se almacenaban únicamente en cruft-packs, pero que se hicieron alcanzables después de un commit que los referenciaba.
En la nueva versión, al reempaquetar archivos pack, se garantizó la conservación de copias adicionales de los objetos alcanzables, almacenados solo en archivos cruft. Este cambio asegura que el conjunto de archivos pack utilizados para almacenar objetos alcanzables no contenga objetos que hagan referencia a otros objetos almacenados fuera de este conjunto. Para excluir el contenido no alcanzable de los archivos cruft de índices multi-paquete (MIDX), se propuso la configuración «repack.MIDXMustContainCruft», lo que permite reducir significativamente el tamaño de dichos índices. La inclusión de esta configuración en el repositorio de GitHub permitió reducir el tamaño de los índices MIDX en un 38%, acelerar la escritura en índices MIDX en un 35% y mejorar el rendimiento de lectura en un 5%.
- Se agregó a la orden «git pack-objects» la opción «—path-walk», que incluye un nuevo método para recopilar información sobre objetos al reempaquetar archivos pack. En lugar de recorrer objetos en orden de revisiones, al usar el modo «—path-walk», los objetos se recorren a través de los caminos de archivos, lo que permite empaquetar todos los objetos con la misma ruta de archivo de una sola vez. Este enfoque permite eliminar la heurística que usa el hashing para determinar la relación del objeto con su ruta de archivo, así como deshacerse de la ordenación de objetos antes de empaquetar. Al utilizar el modo «—path-walk», el tamaño de los archivos pack generados resulta ser significativamente menor que al agrupar objetos mediante hashes.
- Se definió un formato para intercambiar los estados guardados del árbol de trabajo y los índices en el repositorio, creados mediante el comando «git stash». El nuevo formato permite codificar los cambios guardados (registros de stash) como una secuencia de commits. Se proponían los subcomandos «git stash import» y «git stash export» para importar y exportar, que se pueden utilizar para transferir los estados guardados de un sistema a otro y realizar operaciones de push o pull con estos estados como si fueran ramas o etiquetas normales. git stash export —to-ref refs/stashes/my-stash git push origin refs/stashes/my-stash … git fetch origin ‘+refs/stashes/*:refs/stashes/*’ git stash import refs/stashes/my-stash
- En el comando «git cat-file», que muestra el contenido de los objetos especificados, se ha implementado la posibilidad de mostrar información sobre objetos ausentes (por ejemplo, debido a la corrupción del repositorio) y submódulos al utilizar las opciones «—batch» y «—batch-check». Anteriormente, al especificar la ruta al submódulo, el comando «git cat-file —batch-check» mostraba «missing», pero ahora mostrará el identificador del objeto.
- El comando «git log» ha implementado optimizaciones basadas en filtros de Bloom para acelerar la búsqueda en el historial de cambios al especificar filtros con varias rutas de archivos, por ejemplo, «git log — path/to/a path/to/b».
- Se han estabilizado los comandos «git switch» y «git restore», que desde 2019 se consideraban experimentales. Estos comandos se presentan como equivalentes modernos a «git checkout», separando funcionalidades poco relacionadas de este comando, como la manipulación de ramas (cambio y creación) y la restauración de archivos en el directorio de trabajo.
- Se ha declarado obsoleto y se tiene previsto eliminar en la rama Git 3.0 el comando «git whatchanged», que es equivalente a «git log —raw».
- Se ha añadido la opción «—start-after» al comando «git for-each-ref», que puede utilizarse junto con la opción «—count» para organizar la salida paginada.
- Se ha añadido la opción «—compact-summary» a los comandos «git merge» y «git pull» para usar un formato compacto de resumen de cambios en lugar del formato diffstat.
- En la base de código de Git se ha permitido el uso de la palabra clave «bool», que apareció en el estándar C99. También se han documentado algunas características de C99 que se utilizan experimentalmente en Git (por ejemplo, a mediados de 2026 se planea permitir la aplicación de construcciones como «(struct foo){ .member = value };»). Un compilador con soporte para C99 es obligatorio para Git desde 2021, pero las características de la especificación C99 se implementan con extrema cautela para mantener la compatibilidad con compiladores que solo soportan parcialmente este estándar.
- Se han realizado cambios en las reglas para la aceptación de parches que permiten enviar parches bajo un seudónimo, y no solo con el verdadero nombre del desarrollador. Este cambio se alinea con las reglas de aceptación de parches en el núcleo de Linux.
- Se ha actualizado la lista de cambios incompatibles que se aplicarán en la rama Git 3.0. Entre los cambios significativos en la próxima versión de Git 3.0 se destaca la transición por defecto a identificadores de objetos basados en el algoritmo de hash SHA-256 al inicializar nuevos repositorios y la implementación del formato 'reftable' para almacenar en el repositorio referencias a ramas y etiquetas (se activó el almacenamiento de bloques del proyecto JGit, optimizado para almacenar un número muy grande de referencias).
Fuente: opennet.ru
