Se ha presentado el lanzamiento del sistema de control de versiones distribuido Git 2.54. Git se distingue por su alto rendimiento y proporciona herramientas para el desarrollo no lineal basadas en bifurcaciones y fusiones de ramas. Para garantizar la integridad del historial y la resistencia a los cambios retroactivos, se emplea un hashing implícito de toda la historia previa en cada commit, así como la certificación mediante firmas digitales de los desarrolladores de etiquetas y commits individuales. El código de Git se distribuye bajo la licencia GPLv2+.
En comparación con la versión anterior, en esta nueva versión se han aceptado 770 cambios, preparados con la participación de 137 desarrolladores (66 participaron en el desarrollo de Git por primera vez). Principales novedades:
- Se ha implementado el comando «git history», que ofrece capacidades experimentales para reescribir el historial de cambios, más sencillas y seguras de usar que el rebase de commits con el comando «git rebase». Se proporcionan dos operaciones:
- «git history reword » para reescribir el mensaje del commit especificado sin cambiar el árbol de trabajo y el índice (excepto la nota, el resto permanece intacto). Por ejemplo, para corregir un error tipográfico.
- «git history split » para dividir de manera interactiva el commit especificado en dos commits diferentes, moviendo partes seleccionadas del commit original al commit adicional.
En futuras versiones, se espera la adición de comandos adicionales: «git history fixup» para corregir un commit, «git history drop» para eliminar un commit, «git history reorder» para cambiar el orden de los commits y «git history squash» para combinar commits.
- Se ha implementado un nuevo método para definir manejadores (hook) en los archivos de configuración. En lugar de colocar los scripts de los manejadores en el directorio «.git/hooks» en cada repositorio, los comandos para invocar manejadores ahora se pueden especificar directamente en los archivos de configuración. Las configuraciones se pueden vincular al repositorio o indicar en archivos de configuración que son aplicables a todos los repositorios (/etc/gitconfig) o a los repositorios del usuario (~/.gitconfig). Se permite vincular varios manejadores a un solo evento. Los scripts de «.git/hooks» aún se ejecutan, pero se inician después de los manejadores de los archivos de configuración. Para ver la lista de manejadores, se debe utilizar el comando «git hook list», y para desactivar selectivamente la llamada a los manejadores, se utiliza la configuración «hook..enabled = false». [hook «linter»] event = pre-commit command = ~/.bin/linter —cpp20 [hook «no-leaks»] event = pre-commit command = ~/.bin/leak-detector $ git hook list pre-commit global linter ~/.bin/linter —cpp20 local no-leaks ~/.bin/leak-detector
- En el comando «git maintenance», se activa por defecto la estrategia «geometric» («git config set maintenance.strategy geometric»), que permite reducir el tiempo de mantenimiento de grandes monorepositorios. En comparación con la estrategia previamente utilizada, que aplicaba la lógica del comando «git gc», la nueva estrategia evita la reempaquetación de todos los objetos y excluye operaciones excesivamente intensivas en recursos, como la fusión de todos los archivos de paquete (cuando es posible, la fusión se realiza por partes y sin limpiar los objetos eliminados).
- La base de datos de objetos (ODB) y las API relacionadas se han trasladado a una nueva arquitectura basada en el uso de backends configurables. La reestructuración realizada abstrae el formato de almacenamiento de objetos y permitirá en el futuro implementar funcionalidades como backends y formatos de objetos alternativos, por ejemplo, para un almacenamiento más eficiente de grandes archivos binarios o para optimizar el funcionamiento de grandes proveedores de servicios de git.
- En el comando «git repo structure», que genera información sobre la estructura del repositorio, se asegura la visualización no solo del tamaño total, sino también de los objetos más grandes de cada tipo, lo que permite evaluar el tamaño sin usar la herramienta externa git-sizer. $ git repo structure … | * Objetos más grandes | | | * Commits | | | * Tamaño máximo [1] | 17.23 KiB | | * Padres máximos [2] | 10 | | * Árboles | | | * Tamaño máximo [3] | 58.85 KiB | | * Entradas máximas [4] | 1.18 k | | * Blobs | | | * Tamaño máximo [5] | 1019.51 KiB | | * Etiquetas | | | * Tamaño máximo [6] | 7.13 KiB |
- En el comando «git replay», que se utiliza en lugar de «git rebase» para recrear la historia en servidor sin un árbol de trabajo, se incluye por defecto la actualización atómica de referencias (en lugar de listar comandos update-ref para ejecución manual), se implementa la opción «—revert» para deshacer cambios de una serie de commits, se asegura el descarte de commits vacíos resultantes y se añade la posibilidad de recrear la historia hasta el commit raíz.
- En «git rev-list» y comandos similares se añade la opción «—maximal-only» para mostrar solo los commits inalcanzables por otros commits.
- En el comando «git repo info» se añade la opción «—keys» para listar todas las claves conocidas.
- En el comando «git add -p» al navegar entre bloques de código usando las teclas «J» y «K» se asegura la marcación de bloques ya aprobados y omitidos. Se añade la opción «—no-auto-advance» para desactivar el avance automático al siguiente archivo, permitiendo volver a archivos anteriores antes del commit.
- Se ha optimizado la interfaz web «gitweb» para su funcionamiento en dispositivos móviles.
- En el comando «git apply —directory» se asegura la normalización de las rutas de archivos antes de su uso, como «.\/un\/..\/normalized\/path».
- Se documenta la posibilidad de añadir subcomandos propios mediante la colocación de archivos «git-» en el directorio de archivos ejecutables.
- En el comando «git send-email» se añade soporte para certificados de cliente.
- Para el comando «git status» se implementa la configuración «status.compareBranches», a través de la cual se pueden especificar las ramas con las que se comparará la rama actual. [status] compareBranches = @{upstream} @{push}
- En «git rebase» se añade la opción «—trailer» para simplificar la adición de metadatos a todos los commits. git rebase —trailer «Reviewed-by: Test »
- Se ha añadido a la herramienta «git fast-import» la posibilidad de reemplazar las firmas de los commits que se volvieron no válidas después de la importación.
- Se ha añadido soporte para la compactación de índices de múltiples paquetes MIDX (multi-pack index), donde se combinan capas pequeñas del índice MIDX con información sobre la disponibilidad de objetos y sus archivos bitmap asociados, lo que permite reducir el número de capas acumuladas en repositorios existentes desde hace tiempo.
- En la herramienta «git backfill» se ha implementado la posibilidad de especificar revisiones (rangos de commits) y máscaras de rutas (pathspec) para limitar las partes de la historia de cambios cargadas. git backfill main~100..main git backfill — ‘*.c’
- Se han añadido formas alternativas de invocar el comando «git config list» — «git config -l» y «git config —list».
- Se permite el uso de caracteres no ASCII en los nombres de los alias de comando definidos en el archivo de configuración. [alias «obtener»] command = fetch
- Se modificó la visualización de las firmas cuyas claves GPG han expirado, pero que eran válidas en el momento de firmar el commit. Estas firmas ahora se muestran como válidas con una nota sobre la expiración de la clave (anteriormente se resaltaban en rojo, lo que daba la impresión de que eran incorrectas).
- Al acceder a los repositorios a través de HTTP, se ha asegurado el manejo del error con el código 429 (Demasiadas Solicitudes). Las solicitudes que fallaron con este error se consideran ahora no como un problema fatal, sino como un error temporal, para el cual se debe intentar nuevamente después de un tiempo. El retraso antes de repetir se establece a través de la opción «http.retryAfter», el número de reintentos — «http.maxRetries», el tiempo de espera — «http.maxRetryTime».
Fuente: opennet.ru
