¿Qué hay de nuevo en Git 2.55.0?

El proyecto Git lanzó recientemente Git 2.55.0. Veamos algunos aspectos destacados de esta versión, que incluye contribuciones del equipo de Git en GitLab. Lo que se cubre: git-history(1) aprende sobre fixup, demonio fsmonitor para Linux, git push a un grupo remoto, limitación del ancho de las lanes en git log --graph, evolución de Rust en el código de Git, git-grep(1) y git-cherry(1) más rápidos en clones parciales.

git-history(1) aprende sobre fixup. En nuestros aspectos destacados de Git 2.54.0, cubrimos la introducción de git-history(1). En 2.55.0, se añadió un nuevo subcomando para esta herramienta: fixup. Imagina que has realizado algunos cambios y quieres enmendarlos en un commit existente. El enfoque más común es crear un commit fixup y autosquasharlo con git-rebase(1): git commit --fixup=<commit-id> git rebase -i --autosquash <commit-id>^. Hacer esto en dos pasos resulta torpe, especialmente porque requiere un rebase interactivo. En su lugar, puedes utilizar el comando fixup de git-history(1): git history fixup <commit-id>. Esto toma los cambios en etapa y los enmienda en el commit dado. Y como ventaja adicional, dado que estás utilizando git-history(1), todas las demás ramas locales que contienen el commit arreglado también se actualizan. Así que al trabajar con ramas apiladas, arreglar un commit en la pila automáticamente rebaseará todas las ramas relacionadas. Esta función fue implementada por Patrick Steinhardt.

Demonio fsmonitor para Linux. Cuando se trabaja con grandes monorepos, git-status(1) puede ser lento para determinar qué cambió en el árbol de trabajo local porque Git necesita recorrer todo el árbol de trabajo para ver qué archivos están modificados. Para acelerar este proceso, en enero de 2018 se añadió una configuración core.fsmonitor en Git 2.16. En ese momento, tenías que proporcionar tu propia herramienta (como Watchman). Cuando esto se configura, esta herramienta se ejecuta en segundo plano y monitorea cambios en el sistema de archivos. Esto informa a Git que un archivo fue tocado y Git luego verifica si el archivo fue modificado y actualiza el estado en caché. Por lo tanto, cuando el usuario llama a git-status(1), simplemente puede devolver el estado en caché. En abril de 2022, la configuración core.fsmonitor se cambió para aceptar un valor booleano. Cuando esta configuración se establece en true, se utiliza un demonio integrado en Git y ya no es necesaria ninguna herramienta de terceros. Pero este monitor de sistema de archivos solo se implementó para Windows y macOS; el soporte para GNU/Linux aún no existía. Esto cambia en Git 2.55, donde también se añadió soporte para Linux. Para lograr esto, se utiliza inotify(7). Se eligió inotify(7) sobre fanotify(7) porque fanotify(7) requiere privilegios elevados. Sin embargo, esto conlleva una pequeña advertencia: fsmonitor necesita poner un monitor en cada directorio del repositorio. En un repositorio grande, podrías alcanzar el límite de monitores inotify (fs.inotify.max_user_watches), que es posible que necesites aumentar. Estos cambios fueron presentados por Paul Tarjan, basándose en el trabajo de Eric DeCosta y Marziyeh Esipreh.

git push a un grupo remoto. Hace algún tiempo, git-fetch(1) aprendió a obtener desde un grupo de remotos. El siguiente comando configura un grupo de remotos: git config set remotes.forks "origin upstream". Cuando esto está configurado, puedes git-fetch(1) desde este grupo "forks", y luego todos los remotos en esa lista son obtenidos. Esto puede ser útil cuando deseas obtener las actualizaciones de un conjunto de remotos de una vez. Sin embargo, git-push(1) no podía usar grupos remotos. En Git 2.55, se cierra esta brecha y git-push(1) ahora también acepta un grupo remoto. Por ejemplo, si deseas enviar la rama principal al grupo mencionado anteriormente: git push forks main. Al igual que con git-fetch(1), este comando envía las referencias especificadas a cada uno de los remotos en el grupo. Cada remoto es enviado de forma independiente y respeta su propia configuración de mapeo remote.<name>.push y ajustes de espejo. Esta función fue presentada por Usman Akinyemi, sugerida por Junio C Hamano.

Limitación del ancho de lanes en git log --graph. La opción --graph de git-log(1) dibuja una representación ASCII del historial de commits. En un repositorio con muchos colaboradores activos, este gráfico puede volverse muy ancho. Por ejemplo, en el repositorio git.git, este gráfico crece a nueve lanes de ancho después de solo 30 commits: * 26d8d94e94 Algunos temas más antes de -rc2 * 02bb39c5cb Fusionar rama 'js/objects-larger-than-4gb-on-windows-more' |\ | * c6a4629e32 odb: usar size_t para object_info.sizep y las APIs de tamaño | * 7a3a78cc76 packfile, delta: eliminar los wrappers `cast_size_t_to_ulong()` | * 188bac14f7 pack-objects: usar size_t para tamaños de objetos en memoria | * 2d83cc3f84 packfile: ampliar el parámetro de salida size en unpack_entry() a size_t | * 1d43315b31 pack-objects(check_pack_inflate()): usar size_t en lugar de unsigned long | * 33afe87338 patch-delta: usar size_t para tamaños | * 8ea69373a4 compat/msvc: usar _chsize_s para ftruncate * | 8cf57cbec4 Fusionar rama 'kw/gitattributes-typofix' |\ \ | * | 0bf506efd4 gitattributes: corregir atributo eol para scripts Perl * | | 8d96f09e92 Fusionar rama 'js/objects-larger-than-4gb-on-windows' |\ \ \ | * | | ab3810eb6f zlib: limitar correctamente a uLong * | | | 95e20213fa Esperemos que este sea el último lote antes de -rc2 * | | | 8632b5c49d Fusionar rama 'en/commit-graph-timestamp-fix' |\ \ \ \ | * | | | fbcc5408fc commit-graph: usar timestamp_t para acumulador de generación máxima de padres * | | | | 619931f561 Fusionar rama 'dl/posix-unused-warning-clang' |\ \ \ \ \ | * | | | | cf48887610 compat/posix.h: simplificar la comparación de GIT_GNUC_PREREQ() | * | | | | ffd45926dc compat/posix.h: limpiar GIT_GNUC_PREREQ() y UNUSED | * | | | | 689dc92e50 compat/posix.h: habilitar mensajes de advertencia UNUSED para Clang * | | | | | 621962aa7a Fusionar rama 'td/ls-files-pathspec-prefilter' |\ \ \ \ \ \ | * | | | | | 3f5203eeb4 ls-files: filtrar pathspec antes de lstat | | |_|_|_|/ | |/| | | | * | | | | | 0c706d5092 Fusionar rama 'ta/doc-config-adoc-fixes' |\ \ \ \ \ \ | * | | | | | 4fa2c6e045 doc: git-config: escapar el marcado de resaltado erróneo | * | | | | | 042221cccb doc: config/sideband: corregir delimitador de lista de descripciones | * | | | | | 3eb61fda62 doc: config: terminar listas descontroladas * | | | | | | 49cb068fb2 Fusionar rama 'jc/t1400-fifo-cleanup' |\ \ \ \ \ \ \ | * | | | | | | e8f12e0e95 t1400: hacer que la prueba fifo se limpie después de sí misma * | | | | | | | b4970f8448 Fusionar rama 'td/describe-tag-iteration' |\ \ \ \ \ \ \ \ | * | | | | | | | 55088ac8a4 describe: limitar la iteración de ref de forma predeterminada a etiquetas. Esto ocurre porque cada lane continúa hacia abajo hasta el commit desde donde se creó la rama. Esto empuja los mensajes de commit hacia la derecha, dificultando la lectura. Especialmente cuando se alcanza el ancho de la pantalla del terminal, esto se vuelve inutilizable. Git 2.55 añade una nueva opción --graph-lane-limit=<n> para limitar el número de lanes que se dibujan. Cualquier lane más allá del límite se reemplaza con un marcador de truncamiento ~, por lo que queda claro que el gráfico fue recortado: git log --graph --graph-lane-limit=5. Al usar esta opción para los mismos 30 commits mencionados anteriormente, obtendremos: * 26d8d94e94 Algunos temas más antes de -rc2 * 02bb39c5cb Fusionar rama 'js/objects-larger-than-4gb-on-windows-more' |\ | * c6a4629e32 odb: usar size_t para object_info.sizep y las APIs de tamaño | * 7a3a78cc76 packfile, delta: eliminar los wrappers `cast_size_t_to_ulong()` | * 188bac14f7 pack-objects: usar size_t para tamaños de objetos en memoria | * 2d83cc3f84 packfile: ampliar el parámetro de salida size en unpack_entry() a size_t | * 1d43315b31 pack-objects(check_pack_inflate()): usar size_t en lugar de unsigned long | * 33afe87338 patch-delta: usar size_t para tamaños | * 8ea69373a4 compat/msvc: usar _chsize_s para ftruncate * | 8cf57cbec4 Fusionar rama 'kw/gitattributes-typofix' |\ \ | * | 0bf506efd4 gitattributes: corregir atributo eol para scripts Perl * | | 8d96f09e92 Fusionar rama 'js/objects-larger-than-4gb-on-windows' |\ \ \ | * | | ab3810eb6f zlib: limitar correctamente a uLong * | | | 95e20213fa Esperemos que este sea el último lote antes de -rc2 * | | | 8632b5c49d Fusionar rama 'en/commit-graph-timestamp-fix' |\ \ \ \ | * | | | fbcc5408fc commit-graph: usar timestamp_t para acumulador de generación máxima de padres * | | | | 619931f561 Fusionar rama 'dl/posix-unused-warning-clang' |\ \ \ \ \ | * | | | ~ cf48887610 compat/posix.h: simplificar la comparación de GIT_GNUC_PREREQ() | * | | | ~ ffd45926dc compat/posix.h: limpiar GIT_GNUC_PREREQ() y UNUSED | * | | | ~ 689dc92e50 compat/posix.h: habilitar mensajes de advertencia UNUSED para Clang * | | | | ~ 621962aa7a Fusionar rama 'td/ls-files-pathspec-prefilter' |\ \ \ \ \~ | * | | | ~ 3f5203eeb4 ls-files: filtrar pathspec antes de lstat | | |_|_|_~ | |/| | | ~ * | | | | ~ 0c706d5092 Fusionar rama 'ta/doc-config-adoc-fixes' |\ \ \ \ \~ | * | | | ~ 4fa2c6e045 doc: git-config: escapar el marcado de resaltado erróneo | * | | | ~ 042221cccb doc: config/sideband: corregir delimitador de lista de descripciones | * | | | ~ 3eb61fda62 doc: config: terminar listas descontroladas * | | | | ~ 49cb068fb2 Fusionar rama 'jc/t1400-fifo-cleanup' |\ \ \ \ \~ | * | | | ~ e8f12e0e95 t1400: hacer que la prueba fifo se limpie después de sí misma * | | | | ~ b4970f8448 Fusionar rama 'td/describe-tag-iteration' |\ \ \ \ \~ | * | | | ~ 55088ac8a4 describe: limitar la iteración de ref de forma predeterminada a etiquetas. La opción solo tiene sentido junto con --graph. El valor predeterminado es 0, lo que significa sin límite, y los valores cero o negativos se tratan de la misma manera, al igual que --max-parents. Esta función fue presentada por Pablo Sabater.

Evolución de Rust en el código de Git. En marzo de 2025, con el lanzamiento de Git 2.49, se añadió el primer código en Rust al código de Git. Se añadieron enlaces de Rust para permitir que el código en Rust llame a libgit. Pero ninguno de ese código en Rust fue utilizado por los binarios de Git. En noviembre de 2025, en Git 2.52, se introdujo el primer código de producción en Rust en Git. Luego, se añadió una implementación en Rust para el subsistema varint. Este código se compila opcionalmente si el compilador de Rust está disponible, y cuando no lo está, se utiliza la implementación en C. Esto se añadió como una prueba para que los distribuidores comenzaran a preparar sus herramientas para una versión de Git que requiere Rust en algún momento. A principios de este año, en la versión 2.54, se añadió más código en Rust al código base con la introducción del tipo ObjectID. Esto se añadió como parte de los esfuerzos para implementar la interoperabilidad entre SHA-1 y SHA-256. Hasta este lanzamiento, ambos sistemas de compilación, Make y Meson, retrocedían suavemente a la implementación en C si no se encontraba el compilador de Rust. Con este lanzamiento v2.55, se requiere el compilador de Rust a menos que lo desactives explícitamente en el sistema de compilación. Ten en cuenta que esto no afecta a los usuarios de Git. Solo afecta a aquellos que compilan Git desde la fuente. Si compilas Git y no quieres usar Rust, desactívalo con uno de estos comandos: # Meson meson configure -Drust=disabled # Makefile make NO_RUST=YesPlease. Integrar Rust en Git ha sido un esfuerzo comunitario continuo (y en curso) a lo largo de múltiples lanzamientos. Es imposible atribuir esto a una sola persona, pero algunos de los contribuyentes más destacados incluyen a brian m. carlson, Patrick Steinhardt, Ezekiel Newren y Calvin Wan.

git-grep(1) y git-cherry(1) más rápidos en clones parciales. git-clone(1) tiene esta función llamada clon parcial. Esto permite al usuario aplicar un filtro a lo que se envía desde el servidor. En la práctica, esto se hace con la opción --filter. Por ejemplo: git clone --filter=blob:none <remote>. Esto clonará el repositorio, pero esa clonación excluye todos los blobs (es decir, el contenido de los archivos en el árbol). Esto puede acelerar enormemente la clonación, pero viene con el costo de que Git necesita descargar blobs más tarde cuando se utilizan otros comandos que leen el contenido de archivos. Y algunos comandos pueden necesitar muchos blobs faltantes. git-grep(1) es uno de esos comandos, ya que busca en el contenido de los archivos. Para hacer esto, necesita tener esos archivos. Imagina que quieres buscar la palabra "TODO" 100 commits atrás en la historia: git grep TODO HEAD~100. Este comando resuelve el commit HEAD~100 y los árboles asociados a él. Pero esos árboles pueden apuntar a blobs que aún no se han descargado. Anteriormente, cada blob se descargaba por separado. Pero esto se ha mejorado en Git 2.55. En esta versión de Git, las descargas de blobs se agrupan en un solo viaje de negociación con el servidor. Esta agrupación ahora se implementa tanto para git-grep(1) como para git-cherry(1). Este cambio fue presentado por Elijah Newren.

Leer más. Este artículo destacó solo algunas de las contribuciones realizadas por GitLab y la comunidad más amplia de Git para este último lanzamiento. Puedes conocer más sobre esto en el anuncio oficial de lanzamiento del proyecto Git. Además, consulta nuestras publicaciones anteriores en el blog de lanzamientos de Git para ver otros aspectos destacados de las contribuciones de miembros del equipo de GitLab.