Después de dos meses de desarrollo, se ha publicado la versión 2.39 del sistema de control de versiones distribuido Git. Git es uno de los sistemas de control de versiones más populares, fiables y de alto rendimiento, que ofrece herramientas flexibles para el desarrollo no lineal basadas en bifurcaciones y fusiones de ramas. Para asegurar la integridad del historial y la resistencia a cambios retroactivos, se utiliza un hashing implícito de todo el historial anterior en cada commit, además de que se pueden verificar digitalmente ciertas etiquetas y commits por los desarrolladores.
En comparación con la versión anterior, esta nueva versión incluye 483 cambios preparados por la participación de 86 desarrolladores, de los cuales 31 contribuyeron por primera vez. Las principales novedades son:
- Se ha añadido la opción «—group» al comando «git shortlog», que está destinado a mostrar resúmenes estadísticos del historial de cambios, para agrupar arbitrariamente commits por campos que no se limitan al autor o committer. Por ejemplo, para mostrar una lista de desarrolladores con información sobre el número de cambios, incluyendo coautores mencionados en el campo «Co-authored-by», se puede utilizar el comando: git shortlog -ns —group=author —group=trailer:co-authored-by
La salida de shortlog se puede agregar utilizando especificadores de formato y la opción «—group» permite simplificar notablemente la creación de informes complejos y eliminar la necesidad de ejecutar comandos de ordenamiento adicionales. Por ejemplo, para crear un informe sobre cuántos commits se aceptaron para una determinada versión en cada mes, se puede especificar: git shortlog v2.38.0.. —date=’format:%Y-%m’ —group=’’ -s 2 2022-08 47 2022-09 405 2022-10 194 2022-11 5 2022-12 Anteriormente, para realizar una operación similar se requeriría la utilización de las utilidades sort y uniq: git log v2.38.0.. —date=’format:%Y-%m’ —format=’’ | sort | uniq -c
- Se han ampliado las capacidades del mecanismo "cruft packs", destinado a empaquetar objetos inaccesibles que no tienen referencias en el repositorio (no están referenciados por ramas o etiquetas). Los objetos inaccesibles son eliminados por el recolector de basura, pero permanecen en el repositorio durante un tiempo determinado antes de su eliminación para evitar condiciones de carrera. El mecanismo "cruft packs" permite almacenar todos los objetos inaccesibles en un único archivo pack, y los datos sobre el tiempo de modificación de cada objeto se reflejan en una tabla separada, que se almacena en un archivo diferente con la extensión ".mtimes", para que no se crucen con el tiempo general de modificación.
El tiempo que los objetos inaccesibles permanecen en el repositorio antes de su eliminación real se determina mediante la opción "—prune=". A pesar de que la demora antes de la eliminación es un método eficaz y práctico para prevenir daños en el repositorio debido a condiciones de carrera, no es 100% confiable. Para simplificar la recuperación de un repositorio dañado, en la nueva versión se ha incluido la opción para guardar objetos faltantes, añadiendo la opción "—expire-to" al comando "git repack", que permite especificar un archivo para crear una copia externa de todos los objetos eliminados. Por ejemplo, para guardar en el archivo backup.git los objetos inaccesibles que no han cambiado en los últimos 5 minutos, se puede usar el comando: git repack —cruft —cruft-expiration=5.minutes.ago -d —expire-to=../backup.git
- Se ha incrementado significativamente (hasta un 70%) la velocidad de ejecución de la operación "git grep —cached" al buscar en áreas donde se aplica el clonación parcial (sparse-checkout) y que tienen índices parciales (sparse index). Anteriormente, al especificar la opción "—cached", primero se realizaba la búsqueda en el índice normal, y luego en los parciales, lo que causaba demoras notables en la búsqueda en grandes repositorios.
- Se ha acelerado la ejecución en servidor la verificación de la conectividad de nuevos objetos antes de su inclusión en el repositorio al realizar la operación "git push". Gracias a la transición a una verificación que solo tiene en cuenta las referencias declaradas, en un repositorio de prueba con 7 millones de referencias, de las cuales solo el 3% están cubiertas por la operación push, las optimizaciones implementadas han reducido el tiempo de verificación en 4.5 veces.
- Para protegerse contra posibles desbordamientos enteros en el código, se ha limitado el tamaño máximo de los parches procesados en el comando «git apply». Si el tamaño del parche supera 1 GB, se mostrará un error.
- Para protegerse contra posibles vulnerabilidades, se realizaron cambios para limpiar información innecesaria de los encabezados enviados al utilizar el módulo h2h3 con la opción GIT_TRACE_CURL=1 o GIT_CURL_VERBOSE=1 junto con HTTP/2.
- Al realizar la operación de comprobación con una rama que es un enlace simbólico a otra rama, el comando «git symbolic-ref HEAD» ahora muestra el nombre de la rama objetivo en lugar del nombre del enlace simbólico.
- Se añadió soporte para el argumento @{-1} en la opción «—edit-description» («git branch —edit-description @{-1}») para editar la descripción de la última rama.
- Se añadió el comando «git merge-tree —stdin», que permite pasar una lista de parámetros a través de la entrada estándar.
- En los sistemas de archivos de red, el controlador fsmonitor, que rastrea cambios en el sistema de archivos, está desactivado por defecto.
Fuente: opennet.ru
