🥇Git 2.54 | ProHoster

Presentado lanzamiento del sistema distribuido de gestión de textos fuente Git 2.54. Git se distingue por su alto rendimiento y proporciona herramientas de desarrollo no lineal basadas en la ramificación y fusión de ramas. Para garantizar la integridad de la historia y la resistencia a cambios retroactivos, se utiliza una hash implícita de toda la historia anterior en cada commit, así como la certificación mediante firmas digitales de los desarrolladores para etiquetas y commits individuales. Código de Git se distribuye bajo la licencia GPLv2+.

En comparación con la versión anterior, se han aceptado 770 cambios en la nueva versión, preparados con la participación de 137 desarrolladores (66 de los cuales participaron por primera vez en el desarrollo de Git).

Principales novedades:

Se ha implementado el comando «git history», que proporciona capacidades experimentales para reescribir la historia de cambios, siendo más simples 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 en el 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 interactivamente el commit especificado en dos commits diferentes moviendo partes seleccionadas del commit original a un commit adicional.
Se espera que en futuras versiones se añadan 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 scripts de manejadores en el directorio .git/hooks en cada repositorio, ahora se pueden especificar comandos para invocar manejadores directamente en los archivos de configuración. Las configuraciones pueden estar vinculadas al repositorio o indicarse en archivos de configuración que aplican a todos los repositorios (/etc/gitconfig) o al repositorio del usuario (~/.gitconfig). Es posible vincular múltiples manejadores a un solo evento. Los scripts de .git/hooks aún se llaman, pero se ejecutan después de los manejadores de los archivos de configuración. Para ver la lista de manejadores, se debe usar el comando git hook list, y para deshabilitar selectivamente la invocación de manejadores, se debe usar 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 equipo “git maintenance” se utiliza por defecto la estrategia geométrica (git config set maintenance.strategy geometric), que permite reducir el tiempo de mantenimiento de grandes monorepositorios. En comparación con la estrategia anterior, que empleaba una lógica similar a la del comando git gc, la nueva estrategia evita la reempaquetación de todos los objetos y excluye operaciones excesivamente intensivas, como la fusión de todos los archivos de paquetes (cuando es posible, la fusión se realiza por partes y sin limpiar 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 plug-in. La reestructuración llevada a cabo abstrae el formato de almacenamiento de objetos y permitirá en el futuro implementar funciones tales como backends alternativos y formatos de objetos, por ejemplo, para un almacenamiento más eficiente de grandes archivos binarios o para optimizar el funcionamiento de grandes alojamientos de git.
En el equipo “estructura del repositorio git”, proporcionando información sobre la estructura del repositorio, se muestra no solo el tamaño total, sino también los objetos más grandes de cada tipo, lo que permite evaluar el tamaño sin necesidad de utilizar herramientas externas. git-sizer.

En el equipo “git replay”, utilizada como alternativa a git rebase para recrear el historial en el servidor sin un árbol de trabajo, incluye por defecto la actualización atómica de referencias (en lugar de mostrar una lista de comandos update-ref para ejecución manual), se ha implementado la opción —revert para deshacer los cambios de una serie de commits, se eliminan los commits vacíos resultantes y ahora es posible recrear el historial hasta el commit raíz.
En “git rev-list” y comandos similares se ha añadido la opción —maximal-only para mostrar solo commits que no son alcanzables por otros commits.
En el comando “git repo info” se ha agregado la opción —keys para mostrar una lista de todas las claves conocidas.
En el equipo “git add -pAl navegar entre bloques de código con las teclas «J» y «K», se marca automáticamente los bloques ya aprobados y omitidos. Se agregó la opción —no-auto-advance para desactivar el avance automático al siguiente archivo, permitiendo volver a archivos anteriores antes del commit.
Se optimizó la interfaz web «gitweb» para su uso en dispositivos móviles.
En el equipo “git apply –directory» se asegura la normalización de las rutas de archivo, como .\/un\/..\/normalized\/path, antes de su uso.
Se documentó la posibilidad de añadir comandos secundarios personalizados mediante la colocación de archivos git- en el directorio de ejecutables.
En el comando “git send-email» se agregó soporte para certificados de cliente.
Para el comando «git status» se implementó la configuración status.compareBranches, que permite especificar las ramas con las que se comparará la rama actual:

[status] compareBranches = @{upstream} @{push}

En “git rebase» se añadió la opción —trailer para simplificar la adición de metadatos a todos los commits:

git rebase —trailer "Reviewed-by: Test "`

En el comando “git fast-import» se agregó la posibilidad de reemplazar las firmas de los commits que se volvieron inválidas tras la importación.
Se añadió soporte para la compactación de índices MIDX (multi-pack index), donde se combinan pequeñas capas de índices MIDX con información sobre la disponibilidad de objetos y los archivos de mapa de bits asociados, lo que permite reducir el número de capas acumuladas en repositorios antiguos.
En el comando git backfill se implementó la posibilidad de especificar revisiones (rangos de commits) y máscaras de rutas (pathspec) para limitar las partes de la historia de cambios que se cargan:

git backfill main~100..main git backfill — ‘*.c’

Se añadieron formas alternativas para invocar el comando git config list – git config -l y git config —list.
Se permitió el uso de caracteres no ASCII en los nombres de los alias de comandos 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 realizar solicitudes a los repositorios a través de HTTP, se ha implementado el manejo de errores con el código 429 (Demasiadas Solicitudes). Las solicitudes que finalizan con este error ahora se consideran no como un problema fatal, sino como un error temporal, para el cual se debe reintentar después de un tiempo. El retraso antes del reintento 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: linux.org.ru