git.28.0

El proyecto de código abierto de Git acaba de lanzar Git 2.28 con características y correcciones de errores de más de 58 colaboradores, 13 de ellos nuevos. Aquí hay un vistazo a algunas de las características y cambios más interesantes.

Introducción

Cuando se inicia un nuevo repositorio de Git desde cero git init, Git siempre ha creado una primera rama con el nombre de master. En Git 2.28, init.defaultBranchse introduce una nueva opción de configuración para reemplazar el término codificado. (Para obtener más información sobre este cambio, esta declaración de Software Freedom Conservancy es un excelente lugar para buscar).

En Git 2.28, al usar git init, se buscará el valor de init.defaultBranch cuando se crea la primera rama en un nuevo repositorio. Si ese valor no está establecido, el valor init.defaultBranch predeterminado es master. Aquí, es importante tener en cuenta que:

1. El usuario puede establecer esta variable de configuración, y anular el valor predeterminado es tan fácil como:

$ git config --global init.defaultBranch main

2. Esta variable de configuración solo afecta a los nuevos repositorios, y no causa que las ramas de los proyectos existentes cambien de nombre. git clone también seguirá respetando el HEAD del repositorio desde el que está clonando, por lo que no verá un cambio en los nombres de las ramas hasta que un mantenedor inicie uno.

Este cambio es compatible con muchas comunidades, tanto en GitHub como en la comunidad Git más amplia, que están considerando cambiar el nombre de la rama predeterminada de su repositorio master.

Para obtener más información sobre los cambios complementarios que GitHub está realizando, consulte github / renombrar . GitLab y Bitbucket también están haciendo cambios similares.

Changed-path Bloom filters

En Git 2.27, el commit-graph formato de archivo se extendió para almacenar Changed-path Bloom filters. Que significa todo eso? En cierto sentido, esta nueva información ayuda a Git a encontrar puntos en la historia que tocaron un camino dado mucho más rápidamente (por ejemplo git log — <path>, o git blame). Git 2.28 aprovecha estas optimizaciones para ofrecer muchas mejoras de rendimiento considerables.

Antes de entrar en todo eso, vale la pena tomar un repaso a través de commit graphs. En los términos más simples, el commit-graph  almacena información sobre commits. En esencia, commit-graph actúa como un caché para la información de acceso común sobre commits: quiénes son sus padres, cuál es su árbol raíz y cosas así. También almacena información calculada, como el número de generación de un commit y los filtros Changed-path Bloom filters.

¿Por qué almacenar toda esta información? Para comprender la respuesta a esto, es útil tener una comprensión superficial de cómo Git almacena objetos. Git puede almacenar un objeto de dos maneras: ya sea como un objeto suelto (en cuyo caso, el contenido del objeto se almacena en un único archivo único para ese objeto en el disco), o como un objeto empaquetado (en cuyo caso el objeto se ensambla a partir de un formato comprimido en un archivo *.pack ). No importa de qué manera se guarde una confirmación, todavía tenemos que analizarla y descomprimirla antes de poder acceder a sus campos como “árbol raíz” y “padres”.

Con un archivo commit-graph, toda esa información es inmediata: para un commit determinado C, Git sabe exactamente dónde buscar en un archivo commit-graph para todos los campos que almacenamos, y puede leerlos de inmediato, sin necesidad de descompresión o unión. Esto puede ahorrar un poco de tiempo de sus operaciones habituales de Git por sí mismo, pero lo que commit-graph realmente brilla es en los datos calculados que almacena.

Los números de generación son una especie de índice de accesibilidad que puede ayudar a Git a responder preguntas sobre cosas como la accesibilidad y el orden topológico muy rápidamente. Dado que los números de generación no son nuevos en esta versión.

¿Qué hay de nuevo en Git 2.28?

En Git 2.27, el archivo commit-graph aprendió cómo almacenar filtros Changed-path Bloom filters. ¿Qué son los filtros Bloom de ruta cambiada? Un filtro Bloom es un conjunto probabilístico; es decir, se trata de un conjunto de elementos, pero la consulta de ese conjunto en busca de la presencia de algún elemento x devuelve ” x definitivamente no está en este conjunto” o ” x podría estar en este conjunto”, pero nunca ” x definitivamente está en este conjunto”. El commit-graph tiendas de uno de estos filtros Bloom para las confirmaciones que residen en el commit-graph, y que puebla filtro Bloom con una lista de rutas que cambió entre el commit y su primer padre.

Estos filtros Bloom son una gran ayuda para el rendimiento en muchos comandos de Git. El patrón general es algo así como: si tienes un comando Git que calcula diferencias (que a veces puede ser proporcionalmente costoso), tener filtros Bloom le permite a Git calcular muchas menos diferencias omitiendo el cálculo de ciertas confirmaciones cuando sus filtros Bloom regresan “definitivamente no ” para caminos de interés.

Toma git log — /path/to/file, por ejemplo. Antes de Git 2.27, git log tendría que calcular una diferencia sobre cada revisión en su recorrido antes de determinar si mostrarla o no (es decir, si esa diferencia tiene o no entradas para /path/to/file). En Git 2.27 y versiones posteriores, Git puede omitir la computación de muchos de estos diferenciales al consultar el C filtro Bloom de cada commit y consultarlo /path/to/file. Nuevamente: si las consultas devuelven “definitivamente no”, entonces Git sabe que calcular esa diferencia es estrictamente poco interesante.

Debido a que el cálculo de diferencias entre commits puede ser costoso (al menos, en relación con la complejidad del algoritmo para el que se generan), la reducción del número de diferencias calculadas en general puede mejorar en gran medida el rendimiento.

Para probar esto usted mismo, puede ejecutar el comando:

$ git commit-graph write --reachable --changed-paths

Esto genera un archivo commit-graph con la ruta cambiada. Los filtros Bloom están habilitados. Debe ser capaz de ver mejoras en el rendimiento en órdenes como git log — <path>git log -Lgit blame, y todo lo demás se pueden generar diferencias computa primera padres contra un pathspec dado.

Otros cambios

Ahora que hemos hablado sobre algunos de los cambios principales de los últimos lanzamientos, veamos algunas características nuevas más 

  • ¿Alguna vez has estado buscando las partes de la historia que cambiaron algún camino? Tal vez solo quiera saber sobre los commits que han modificado algún archivo, y que se pueden encontrar fácilmente ejecutando. A veces git log — <path> , puede que le interese no solo qué commits <path>, sino qué commits de fusión llevaron esos commits a la línea principal de desarrollo ¿Alguna vez has encontrado esas fusiones difíciles de encontrar? No estás solo. En la mayoría de los casos, Git omitirá mostrarle ese tipo de fusiones git log — <path>, ya que esas confirmaciones no modifican <path> por sí mismas. Ahora puede volver a ver esas fusiones con la nueva bandera de Git  –show-pulls para revisar los comandos de marcha, como git loggit rev-list. Para una vista particularmente informativa, intente:$ git log –oneline –graph –show-pulls — <path>
  • Cuando se ejecuta en un repositorio git pull cuando está rastreando una rama remota, puede suceder una de cuatro cosas: puede que no haya cambios, cambios en el servidor, el cliente o ambos. Mientras no haya cambios en ambas direcciones, resolver la diferencia es sencillo: cuando no hay ningún cambio, no hay nada que hacer. Cuando el servidor está estrictamente por delante del cliente, el cliente avanza rápidamente al estado en el servidor. Pero, cuando hay cambios tanto en el cliente como en el servidor: ¿qué sucede? Eso depende de si no tienes la configuración pull.rebase . Si lo hace, su rama se reajusta en la parte superior de donde está tirando, y de lo contrario, se realiza una fusión. Estas fusiones pueden abarrotar su historial y puede ser difícil retroceder sin comenzar desde cero. Git 2.28 ahora le advierte sobre este caso (específicamente, cuando pull.rebase está desarmado y no especificó explícitamente –[no-]rebase como argumento para git pull).
  • Git ahora incluye un flujo de trabajo de acciones de GitHub que puede usar para ejecutar las propias pruebas de integración de Git en una variedad de plataformas y compiladores. No se requiere ningún esfuerzo adicional de su parte: si tiene una bifurcación de GitHub, cada commit se ejecutará a través de la variedad de pruebas necesarias para validar su cambio. Pero espera: ¿Git no usa una lista de correo para el desarrollo? Sí, pero ahora puedes usar GitGitGadget en el repositorio. Esto significa que puede abrir una solicitud de extracción y hacer que GitGitGadget la envíe a la lista de correo en su nombre. Entonces, si se siente más cómodo contribuyendo a Git de esa manera en lugar de redactar correos electrónicos manualmente, ahora puede contribuir a Git de principio a fin usando GitHub. git/git git/git
  • Por otro lado, si no le importa enviar un correo electrónico o dos, ahora es mucho más fácil interactuar con la lista de correo de Git cuando encuentra un error al ejecutarlo git bugreport. La ejecución de este nuevo comando lo abrirá $EDITOR con una forma de preguntas rellenada previamente que será útil para depurar su problema. También incluye información útil sobre su sistema, como la arquitectura de su CPU, qué versión de Git está ejecutando, etc. Cuando haya terminado, puede enviar ese archivo como el cuerpo de un correo electrónico a la lista de correo de Git y puede estar seguro de que ha abierto un informe de error útil.
  • Hemos hablado varias veces sobre Git clean y los smudge filtros y el process filtro correspondiente (que simula múltiples cleansmudge filtros en un solo proceso). Hasta hace poco, el protocolo para estos filtros ha sido relativamente sencillo: Git suministra un extremo del contenido y el filtro produce el otro. En Git 2.27, se proporciona más información sobre el protocolo, como metadatos sobre la rama que se desprotege en el caso de git checkout, o el control remoto que se contactó en caso de a git fetch. Esta nueva información podría usarse en herramientas como, por ejemplo, Git LFS para averiguar con qué control remoto contactar para obtener datos adicionales.

El resto del iceberg

Eso es solo una muestra de los cambios de los últimos lanzamientos. Para obtener más información, consulte las notas de la versión 2.27 y 2.28 , o cualquier versión anterior en el repositorio de Git.

Fuente: https://github.blog/2020-07-27-highlights-from-git-2-28/

Etiquetas:

Sobre el Autor

0 0 vote
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments