Después de dos meses de desarrollo, se publicó el lanzamiento del sistema distribuido de control de versiones Git 2.35. Git es uno de los sistemas de control de versiones más populares, fiables y de alto rendimiento, que proporciona herramientas flexibles para el desarrollo no lineal, basándose en el ramificado y la fusión de ramas. Para garantizar la integridad de la historia y la resistencia a los cambios retroactivos, se utiliza un hash implícito de toda la historia anterior en cada commit, también es posible verificar digitalmente las firmas de los desarrolladores en etiquetas y commits individuales.
En comparación con la versión anterior, en esta nueva versión se han incorporado 494 cambios, preparados con la participación de 93 desarrolladores, de los cuales 35 participaron por primera vez en el desarrollo. Las principales novedades son:
- Se han ampliado las capacidades de uso de claves SSH para certificar objetos de Git con una firma digital. Para diferenciar la vigencia de múltiples claves, se ha añadido soporte para las directivas de OpenSSH "valid-before" y "valid-after", mediante las cuales se puede garantizar un funcionamiento correcto con firmas después de la rotación de la clave de uno de los desarrolladores. Anteriormente, surgía un problema al mezclar las firmas con la antigua y la nueva clave: si se eliminaba la antigua clave, no se podría verificar las firmas realizadas con ella, y si se mantenía, se conservaría la posibilidad de crear nuevas firmas con la antigua clave, la cual ya había sido reemplazada por otra. Con "valid-before" y "valid-after" se puede delimitar el ámbito de las claves según el momento de creación de la firma.
- En la configuración merge.conflictStyle, que permite elegir el modo de presentación de la información sobre conflictos durante la fusión, ahora se ha añadido soporte para el modo "zdiff3", que mueve fuera del área de conflicto todas las líneas típicas indicadas al principio o al final del conflicto, lo que permite lograr una representación de la información más compacta.
- El comando «git stash» ha añadido el modo «—staged», que permite ocultar solo los cambios añadidos al índice, por ejemplo, en situaciones donde es necesario posponer temporalmente parte de cambios complejos para agregar primero lo que ya está listo, y manejar lo demás más adelante. Este modo se asemeja al comando «git commit», que registra solo los cambios colocados en el índice, pero en lugar de crear un nuevo compromiso en «git stash —staged», el resultado se guarda en el área temporal de stash. Una vez que se necesiten los cambios, se pueden recuperar con el comando «git stash pop».
- El comando «git log» ha añadido un nuevo especificador de formato «—format=%(describe)», que permite combinar la salida de «git log» con el resultado de la ejecución del comando «git describe». Los parámetros para «git describe» se especifican directamente dentro del especificador («—format=%(describe:match=,exclude=)»), en el cual también se pueden incluir etiquetas resumidas («—format=%(describe:tags=)») y configurar la cantidad de caracteres hexadecimales para la identificación de objetos («—format=%(describe:abbrev=)»). Por ejemplo, para mostrar los 8 últimos compromisos cuyas etiquetas no tienen la etiqueta de candidato de lanzamiento, y especificar identificadores de 8 caracteres, se puede usar el comando: $ git log -8 —format='%(describe:exclude=*-rc*,abbrev=13)' v2.34.1-646-gaf4e5f569bc89 v2.34.1-644-g0330edb239c24 v2.33.1-641-g15f002812f858 v2.34.1-643-g2b95d94b056ab v2.34.1-642-gb56bd95bbc8f7 v2.34.1-203-gffb9f2980902d v2.34.1-640-gdf3c41adeb212 v2.34.1-639-g36b65715a4132
- En la configuración de user.signingKey se ha implementado soporte para nuevos tipos de claves, no limitándose al tipo «ssh-» y a la especificación de la ruta completa al archivo de clave. Los tipos alternativos se especifican utilizando el prefijo «key::», por ejemplo, «key::ecdsa-sha2-nistp256» para claves ECDSA.
- La velocidad de generación de la lista de cambios en el modo «—histogram» ha mejorado significativamente, así como al usar la opción «—color-moved-ws», que controla el resaltado de espacios en el diff de color.
- En el comando «git jump», utilizado para proporcionar a Vim información sobre transiciones precisas a una posición buscada en un archivo al resolver conflictos de fusión, revisar diferencias o ejecutar una operación de búsqueda, se ha añadido la capacidad de restringir los conflictos de fusión abarcados. Por ejemplo, para limitar las operaciones solo al directorio «foo» se puede especificar «git jump merge — foo», y para excluir el directorio «Documentation» de su procesamiento se puede usar «git jump merge — ‘:^Documentation'».
- Se ha trabajado en la estandarización del uso del tipo «size_t» en lugar de «unsigned long» para los valores que representan el tamaño de los objetos, lo que ha permitido aplicar los filtros «clean» y «smudge» a archivos de más de 4 GB en todas las plataformas, incluidas las que tienen el modelo de datos LLP64, donde el tipo «unsigned long» está limitado a 4 bytes.
- Se ha añadido la opción «—empty=(stop|drop|keep)» al comando «git am», que permite elegir el comportamiento para correos vacíos sin parches al analizar parches desde el buzón. El valor «stop» finalizará toda la operación de aplicación de parches, «drop» omitirá el parche vacío y «keep» creará un commit vacío.
- Se ha agregado soporte para índices parciales (sparse index) en los comandos «git reset», «git diff», «git blame», «git fetch», «git pull» y «git ls-files», lo que permite mejorar el rendimiento y ahorrar espacio en repositorios donde se realizan operaciones de clonación parcial (sparse-checkout).
- Se ha declarado obsoleto el comando «git sparse-checkout init», por lo que se debe utilizar «git sparse-checkout set» en su lugar.
- Se ha añadido una implementación inicial del nuevo backend «reftable» para almacenar referencias como ramas y etiquetas en el repositorio. Este nuevo backend utiliza un almacenamiento en bloques aplicado en el proyecto JGit y optimizado para almacenar un número muy grande de referencias. Actualmente, el backend no está integrado con el sistema de referencias (refs) y no está listo para su uso práctico.
- La paleta de colores del comando «git grep» se ha alineado con la utilidad GNU grep.
Fuente: opennet.ru
