✅ CONTENIDO_COMPLETO | Traducido automáticamente del inglés
🍭 En esta nota me enfoqué en el impacto para experiencia de desarrollo, interfaces y ergonomía del producto.
El proyecto Git de código abierto acaba de lanzar Git 2.55. Aquí está un vistazo de GitHub a algunas de las características y cambios más interesantes introducidos desde la última vez. Taylor Blau · @ttaylorr 29 de junio de 2026 | 14 minutos Compartir: El proyecto Git de código abierto acaba de lanzar Git 2.55 con funciones y correcciones de errores de más de 100 contribuyentes, 33 de ellos nuevos.
La última vez que hablamos con usted sobre lo último en Git fue cuando se lanzó 2.54. Para celebrar este lanzamiento más reciente, aquí está un vistazo de GitHub a algunas de las características y cambios más interesantes introducidos desde la última vez. Reempaquetado con índices incrementales de paquetes múltiples Los lectores recurrentes de esta serie pueden recordar nuestra cobertura de índices incrementales de paquetes múltiples y mapas de bits incrementales de accesibilidad de paquetes múltiples.
En caso de que necesite un repaso, aquí está la versión corta. Git almacena el contenido de su repositorio como objetos individuales: confirmaciones, árboles y blobs. Esos objetos suelen vivir en paquetes de archivos, que son colecciones comprimidas de objetos.
Un archivo de paquete tiene un índice de paquete correspondiente que le permite a Git localizar rápidamente cualquier objeto dentro del paquete. Pero los repositorios grandes no suelen tener un solo archivo de paquete: con el tiempo, las búsquedas, los envíos, las tareas de mantenimiento y los reempaquetados pueden dejar muchos paquetes atrás. Un índice de paquetes múltiples (o MIDX) le da a Git un índice único sobre muchos paquetes.
En lugar de abrir y buscar el índice individual de cada paquete, Git puede preguntarle al MIDX qué paquete contiene un objeto determinado y en qué desplazamiento. Esto es especialmente útil para repositorios grandes y es uno de los pilares detrás de la estrategia de mantenimiento de repositorios de GitHub. Como cubrimos cuando Git 2.47 introdujo el formato MIDX incremental, un repositorio puede almacenar su MIDX como una cadena de capas en lugar de como un único MIDX que cubra cada paquete.
Un MIDX de un solo archivo es simple y eficiente de leer, pero tiene un costo de mantenimiento importante; Dado que ese archivo incluye todos los paquetes que cubre, incluso una pequeña actualización puede requerir una escritura grande en un repositorio que ya es grande. Los MIDX incrementales abordan esto almacenando una cadena de capas MIDX. Cada capa cubre una colección de paquetes y el archivo de cadena registra el orden de esas capas.
Agregar una nueva capa al final de la cadena no invalida las capas más antiguas, por lo que Git puede indexar paquetes recién creados sin reescribir un solo MIDX que cubra todo el repositorio. Git 2.55 le enseña a git repack cómo escribir esas cadenas MIDX incrementales directamente: $ git repack –write-midx=incremental Sin ninguna otra opción, ese modo es de solo agregar: Git escribe una nueva capa para los paquetes creados por el repack y deja las capas existentes en paz. Esto ya es útil cuando desea minimizar la cantidad de metadatos que se reescriben durante una ejecución de mantenimiento.
Pero una cadena de sólo anexos no puede crecer para siempre. Si cada ejecución de mantenimiento agrega una nueva capa, eventualmente la cadena misma se convierte en lo que necesita mantener. Git 2.55 también admite la combinación –write-midx=incremental con reempaquetado geométrico: $ git repack –write-midx=incremental –geometric=2 -d Cuando esos modos se usan juntos, cada reempaquetado crea una nueva capa de punta y luego decide si las capas adyacentes deben compactarse juntas.
La regla predeterminada está controlada por repack.midxSplitFactor: si el recuento de objetos acumulados en las capas más nuevas crece lo suficiente en relación con la siguiente capa anterior, Git fusiona esas capas en una única capa de reemplazo. De lo contrario, las capas más antiguas no se modifican. En un nivel alto, el algoritmo funciona así.
A continuación, N N se refiere al valor de repack.midxNewLayerThreshold y f f se refiere al valor de repack.midxSplitFactor: Elija los paquetes sin MIDX como candidatos de reempaquetado geométrico. Si la capa MIDX punta tiene al menos N N paquetes, inclúyalos también como candidatos. Aplique la regla de reempaquetado geométrico habitual a ese conjunto candidato y escriba una nueva capa MIDX de punta que cubra los paquetes resultantes.
Compacte las capas MIDX adyacentes mientras el recuento de objetos acumulados de las capas más nuevas…
📰 Fuente Original
General – Leer artículo completo →
📌 Nota: Este artículo fue traducido automáticamente. Para la versión original en inglés, visita el enlace de la fuente.
🍭 Curada por Jicaleta con ojo en UX, frontend y claridad para devs.