Lanzamiento del sistema de control de código fuente distribuido Git 2.26

Disponible lanzamiento del sistema de control de código fuente distribuido Git 2.26.0. Git es uno de los sistemas de control de versiones más populares, fiables y de alto rendimiento que proporciona herramientas de desarrollo no lineal flexibles basadas en bifurcaciones y fusiones de bifurcaciones. Para garantizar la integridad del historial y la resistencia a los cambios retroactivos, se utiliza un hash implícito de todo el historial anterior en cada confirmación, también es posible verificar etiquetas individuales y confirmaciones con firmas digitales de los desarrolladores.

En comparación con la versión anterior, la nueva versión incluyó 504 cambios, elaborados con la participación de 64 desarrolladores, de los cuales 12 participaron en el desarrollo por primera vez. El principal innovaciones:

  • El valor predeterminado ha sido cambiado a segunda versión Protocolo de comunicación Git, que se utiliza cuando un cliente se conecta de forma remota a un servidor Git. La segunda versión del protocolo se destaca por brindar la capacidad de filtrar ramas y etiquetas en el lado del servidor, devolviendo una lista abreviada de enlaces al cliente. Anteriormente, cualquier comando de extracción siempre enviaba al cliente la lista completa de referencias en todo el repositorio, incluso cuando el cliente solo estaba actualizando una rama o verificando que su copia del repositorio estuviera actualizada. Otra innovación notable es la capacidad de agregar nuevas capacidades al protocolo a medida que haya nuevas funciones disponibles en el kit de herramientas. El código del cliente sigue siendo compatible con el protocolo anterior y puede continuar funcionando con servidores nuevos y antiguos, volviendo automáticamente a la primera versión si el servidor no admite la segunda.
  • La opción "-show-scope" se ha agregado al comando "git config", lo que facilita la identificación del lugar donde se definen ciertas configuraciones. Git le permite definir configuraciones en diferentes lugares: en el repositorio (.git/info/config), en el directorio de usuario (~/.gitconfig), en el archivo de configuración de todo el sistema (/etc/gitconfig) y mediante comando opciones de línea y variables de entorno. Al ejecutar "git config" es bastante difícil entender dónde está definida exactamente la configuración deseada. Para resolver este problema, la opción “--show-origin” estaba disponible, pero solo muestra la ruta al archivo en el que está definida la configuración, lo cual es útil si desea editar el archivo, pero no ayuda si Es necesario cambiar el valor a través de "git config" usando las opciones "--system", "--global" o "-local". La nueva opción "--show-scope" muestra el contexto de definición de la variable y se puede utilizar junto con -show-origin:

    $ git --list --show-scope --show-origin
    archivo global:/home/user/.gitconfig diff.interhunkcontext=1
    archivo global:/home/user/.gitconfig push.default=current
    […] archivo local:.git/config rama.master.remote=origin
    archivo local:.git/config branch.master.merge=refs/heads/master

    $ git config --show-scope --get-regexp 'diff.*'
    diferencia global ancho del gráfico 35
    diferencia local color llanura movida

    $ git config --global --unset diff.statgraphwidth

  • En la configuración de enlace cartas credenciales Se permite el uso de máscaras en las URL. Cualquier configuración HTTP y credenciales en Git se pueden configurar tanto para todas las conexiones (http.extraHeader, credential.helper) como para conexiones basadas en URL (credential.https://example.com.helper, credential.https: //example. com.helper). Hasta ahora, los comodines como *.example.com solo se permitían para la configuración HTTP, pero no se admitían para el enlace de credenciales. En Git 2.26, estas diferencias se eliminan y, por ejemplo, para vincular un nombre de usuario a todos los subdominios ahora puedes especificar:

    [credencial "https://*.example.com"]

    nombre de usuario = taylorr

  • Continúa la expansión del soporte experimental para la clonación parcial (clones parciales), lo que le permite transferir solo una parte de los datos y trabajar con una copia incompleta del repositorio. La nueva versión agrega un nuevo comando "git sparse-checkout add", que le permite agregar directorios individuales para aplicar la operación "checkout" solo a una parte del árbol de trabajo, en lugar de enumerar todos esos directorios a la vez mediante el comando "git conjunto de pago disperso" (puede agregar uno por uno los directorios, sin volver a especificar la lista completa cada vez).
    Por ejemplo, para clonar un repositorio git/git sin comprometer blobs, limitar la extracción solo al directorio raíz de la copia de trabajo y marcar por separado la extracción para los directorios "t" y "Documentación", podría especificar:

    $ git clone --filter=blob:none --sparse [email protected]:git/git.git

    $ cd git
    $ git sparse-checkout init --cono

    $ git sparse-checkout agregar t
    :
    $ git sparse-checkout agregar documentación
    :
    $ git lista de pago dispersa
    Documentación
    t

  • Se ha mejorado significativamente el rendimiento del comando “git grep”, utilizado para buscar tanto el contenido actual del repositorio como las revisiones históricas. Para acelerar la búsqueda, era posible escanear el contenido del árbol de trabajo utilizando múltiples subprocesos (“git grep –threads”), pero la búsqueda en revisiones históricas era de un solo subproceso. Ahora esta limitación se ha eliminado implementando la capacidad de paralelizar las operaciones de lectura desde el almacenamiento de objetos. De forma predeterminada, la cantidad de subprocesos se establece igual a la cantidad de núcleos de CPU, lo que en la mayoría de los casos ahora no requiere configurar explícitamente la opción "-threads".
  • Se agregó soporte para el autocompletado de entrada de subcomandos, rutas, enlaces y otros argumentos del comando "git worktree", lo que le permite trabajar con varias copias de trabajo del repositorio.
  • Se agregó soporte para colores brillantes que tienen secuencias de escape ANSI. Por ejemplo, en la configuración de colores resaltados “git config –color” o “git diff –color-moved” puedes especificar “%C(brightblue)” mediante la opción “--format” para azul brillante.
  • Se agregó una nueva versión del script. fsmonitor-vigilante, proporcionando integración con el mecanismo. Vigilante de Facebook para acelerar el seguimiento de los cambios de archivos y la aparición de nuevos archivos. Después de actualizar se requiere git заменить gancho en el repositorio.
  • Se agregaron optimizaciones para acelerar los clones parciales cuando se usan mapas de bits.
    (maquinaria de mapa de bits) para evitar una búsqueda completa de todos los objetos al filtrar la salida. Ahora se realiza la comprobación de blobs (—filter=blob:none y —filter=blob:limit=n) durante la clonación parcial.
    significativamente más rápido. GitHub anunció parches con estas optimizaciones y soporte experimental para clonación parcial.

  • El comando "git rebase" se ha movido a un backend diferente, utilizando el mecanismo predeterminado de 'fusión' (usado anteriormente para "rebase -i") en lugar de 'patch+apply'. Los backends difieren en algunas pequeñas formas, por ejemplo, después de continuar una operación después de resolver un conflicto (git rebase --continue), el nuevo backend ofrece editar el mensaje de confirmación, mientras que el anterior simplemente usaba el mensaje anterior. Para volver al comportamiento anterior, puede usar la opción "--apply" o configurar la variable de configuración 'rebase.backend' en 'apply'.
  • Un ejemplo de un controlador para los parámetros de autenticación especificados a través de .netrc se ha reducido a un formato adecuado para su uso inmediato.
  • Se agregó la configuración gpg.minTrustLevel para establecer el nivel de confianza mínimo para varios elementos que realizan la verificación de firma digital.
  • Se agregó la opción "--pathspec-from-file" a "git rm" y "git stash".
  • Continuó la mejora de los conjuntos de pruebas en preparación para la transición al algoritmo hash SHA-2 en lugar de SHA-1.

Fuente: opennet.ru

Añadir un comentario