Después de dos meses de desarrollo, se lanzó el sistema de control de código fuente distribuido Git 2.39. Git es uno de los sistemas de control de versiones más populares, confiables y de alto rendimiento, y proporciona herramientas de desarrollo no lineales flexibles basadas en ramificaciones y fusiones. Para garantizar la integridad del historial y la resistencia a cambios retroactivos, en cada confirmación se utiliza el hash implícito de todo el historial anterior; también es posible certificar etiquetas individuales y confirmaciones con firmas digitales de los desarrolladores.
En comparación con la versión anterior, la nueva versión incluyó 483 cambios, elaborados con la participación de 86 desarrolladores, de los cuales 31 participaron en el desarrollo por primera vez. Principales innovaciones:
- El comando "git shortlog", diseñado para mostrar resúmenes con estadísticas del historial de cambios, ha agregado una opción "-group" para agrupar arbitrariamente confirmaciones por campos que no se limitan al autor o al autor de la confirmación. Por ejemplo, para mostrar una lista de desarrolladores con información sobre la cantidad de cambios, teniendo en cuenta los ayudantes mencionados en el campo "Coautor de", puede usar el comando: git shortlog -ns --group=author - -group=trailer:coautor-por
La salida de Shortlog se puede agregar utilizando especificadores de formato, y la opción "--group" puede simplificar significativamente la creación de informes complejos y eliminar la necesidad de comandos de clasificación adicionales. Por ejemplo, para crear un informe con información sobre cuántas confirmaciones para una versión determinada se aceptaron cada mes, puede especificar: git shortlog v2.38.0.. —date='format:%Y-%m' —group=' %cd' -s 2 2022-08 47 2022-09 405 2022-10 194 2022-11 5 2022-12 Anteriormente, para realizar una operación similar hubiera sido necesario utilizar las utilidades sort y uniq: git log v2.38.0 .. —fecha='formato:%Y -%m' —formato='%cd' | ordenar | único -c
- Se han ampliado las capacidades del mecanismo "cruft packs", diseñado para empaquetar objetos inalcanzables a los que no se hace referencia en el repositorio (no a los que se hace referencia mediante ramas o etiquetas). El recolector de basura elimina los objetos inalcanzables, pero permanecen en el repositorio durante un tiempo determinado antes de eliminarlos para evitar condiciones de carrera. El mecanismo de "paquetes crudos" le permite almacenar todos los objetos inalcanzables en un archivo de paquete y mostrar datos sobre el tiempo de modificación de cada objeto en una tabla separada, almacenada en un archivo separado con la extensión ".mtimes", para que no no se superponga con el tiempo total de modificación.
El período de tiempo que los objetos inalcanzables permanecen en el repositorio antes de que realmente se eliminen está determinado por la opción “—prune=" " Sin embargo, si bien retrasar antes de eliminar es una forma bastante efectiva y práctica de prevenir la corrupción del repositorio debido a condiciones de carrera, no es 100% confiable. Para facilitar la restauración de un repositorio dañado, la nueva versión ofrece la posibilidad de guardar objetos faltantes agregando la opción “--expire-to” al comando “git repack”, que le permite especificar un archivo para crear un repositorio externo. copia de todos los objetos eliminados. Por ejemplo, para guardar objetos inalcanzables que no han cambiado en los últimos 5 minutos en el archivo backup.git, puede usar el comando: git repack --cruft --cruft-expiration=5.minutos.ago -d --expire -to=../backup.git
- Aumentó significativamente (hasta un 70%) la velocidad de la operación "git grep -cached" al buscar en áreas que utilizan clonación parcial (sparse-checkout) y para las cuales existen índices parciales (índice disperso). Anteriormente, al especificar la opción "-cached", la búsqueda se realizaba primero en el índice normal y luego en los parciales, lo que provocaba retrasos notables en la búsqueda en repositorios grandes.
- Se ha acelerado la verificación por parte del servidor de la coherencia de los nuevos objetos antes de colocarlos en el repositorio durante la operación "git push". Al pasar a contabilizar únicamente los enlaces declarados durante la verificación, en un repositorio de prueba con 7 millones de enlaces, de los cuales solo el 3% están cubiertos por la operación push, las optimizaciones realizadas permitieron reducir el tiempo de verificación en 4.5 veces.
- Para protegerse contra posibles desbordamientos de enteros en el código, el comando "git apply" limita el tamaño máximo de los parches que se pueden procesar. Si el tamaño del parche supera 1 GB, ahora se mostrará un error.
- Para protegerse contra posibles vulnerabilidades, se han realizado cambios para limpiar información innecesaria de los encabezados configurados cuando se usa el módulo h2h3 con la opción GIT_TRACE_CURL=1 o GIT_CURL_VERBOSE=1 junto con HTTP/2.
- Al realizar un check-out en una rama que es un enlace simbólico a otra rama, el comando "git simbólico-ref HEAD" ahora muestra el nombre de la rama de destino en lugar del nombre del enlace simbólico.
- Se agregó soporte para el argumento @{-1} a la opción “--edit-description” (“git branch —edit-description @{-1}”) para editar la descripción de una rama anterior.
- Se agregó el comando "git merge-tree --stdin" para pasar una lista de opciones a través de la entrada estándar.
- En los sistemas de archivos de red, el controlador fsmonitor, que monitorea los cambios en el sistema de archivos, está deshabilitado de forma predeterminada.
Fuente: opennet.ru