Nouveautés de Git 2.55.0

Le projet Git a récemment publié Git 2.55.0. Passons en revue quelques-unes des nouveautés marquantes de cette release, qui comprend des contributions de l'équipe Git chez GitLab.

git-history(1) : nouvelle commande fixup

Dans les nouveautés marquantes de Git 2.54.0, nous avons présenté l'introduction de git-history(1). Dans la release 2.55.0, une nouvelle sous-commande a été ajoutée à cet outil : fixup.

Imaginez que vous avez apporté des modifications et que vous souhaitez les intégrer à un commit existant. L'approche la plus courante consiste à créer un commit fixup, puis à le regrouper automatiquement (« autosquash ») avec git-rebase(1) :

      git commit --fixup=<commit-id>
git rebase -i --autosquash <commit-id>^

    

Effectuer cette opération en deux étapes est fastidieux, d'autant plus que cela nécessite un rebasage interactif. À la place, utilisez la commande fixup de git-history(1) :

      git history fixup <commit-id>

    

Celle-ci intègre les modifications indexées au commit indiqué. Avantage supplémentaire : étant donné que vous utilisez git-history(1), toutes les autres branches locales qui contiennent le commit corrigé sont également mises à jour. Ainsi, lorsque vous travaillez avec des branches empilées, corriger un commit de la pile rebase automatiquement toutes les branches associées.

Cette fonctionnalité a été implémentée par Patrick Steinhardt.

Daemon fsmonitor pour Linux

Lorsque vous travaillez avec de grands monorepos, git-status(1) est parfois lent à déterminer ce qui a changé dans l'arborescence de travail locale, car Git doit en parcourir l'intégralité pour repérer les fichiers modifiés. Pour accélérer ce processus, le paramètre core.fsmonitor a été ajouté en janvier 2018 dans Git 2.16. À l'époque, vous deviez fournir votre propre outil (comme Watchman). Une fois configuré, cet outil s'exécute en arrière-plan et surveille les modifications du système de fichiers. Il informe Git qu'un fichier est concerné ; Git vérifie alors si le fichier a été modifié et met à jour le statut mis en cache. Ensuite, chaque fois que l'utilisateur appelle git-status(1), la commande peut simplement renvoyer le statut mis en cache.

En avril 2022, le paramètre core.fsmonitor a été modifié pour accepter une valeur booléenne. Lorsque ce paramètre est défini sur true, un daemon intégré à Git est utilisé et plus aucun outil tiers n'est nécessaire. Mais ce moniteur de système de fichiers n'était implémenté que pour Windows et macOS ; la prise en charge de GNU/Linux n'existait pas encore.

C'est désormais chose faite avec Git 2.55, qui prend en charge Linux. Pour y parvenir, nous avons décidé d'utiliser inotify(7) plutôt que fanotify(7), car fanotify(7) nécessite des privilèges élevés. Il y a toutefois un petit bémol : fsmonitor doit surveiller chaque répertoire du dépôt. Dans un grand dépôt, vous pourriez atteindre la limite de surveillance inotify (fs.inotify.max_user_watches), que vous devrez peut-être augmenter.

Ces modifications ont été soumises par Paul Tarjan à partir des travaux d'Eric DeCosta et de Marziyeh Esipreh.

git push vers un groupe de dépôts distants

Il y a déjà un certain temps, git-fetch(1) a appris à gérer la récupération depuis un groupe de dépôts distants.

La commande suivante configure un groupe de dépôts distants :

      git config set remotes.forks "origin upstream"

    

Une fois cette configuration en place, vous pouvez utiliser git-fetch(1) sur ce groupe « forks » ; tous les dépôts distants de la liste sont alors récupérés. Cette commande peut s'avérer utile lorsque vous souhaitez obtenir les mises à jour d'un ensemble de dépôts distants en une seule fois.

git-push(1), en revanche, ne pouvait pas utiliser les groupes de dépôts distants.

Git 2.55 comble cette lacune : git-push(1) accepte désormais aussi un groupe de dépôts distants. Voici un exemple de push de la branche main vers le groupe mentionné ci-dessus :

      git push forks main

    

Comme avec git-fetch(1), cette commande effectue un push des références spécifiées vers chaque dépôt distant du groupe. Chaque dépôt distant fait l'objet d'un push indépendant et respecte son propre mappage remote.<name>.push ainsi que ses paramètres de miroir.

Cette fonctionnalité a été soumise par Usman Akinyemi, sur la base d'une suggestion de Junio C Hamano.

Limiter le nombre de voies de git log --graph

L'option --graph de git-log(1) dessine une représentation ASCII de l'historique des commits. Dans un dépôt comptant de nombreux contributeurs actifs, ce graphe peut s'agrandir considérablement. Par exemple, sur le dépôt git.git, ce graphe atteint neuf voies (« lanes ») en largeur après seulement 30 commits :

      * 26d8d94e94 A few more topics before -rc2
*   02bb39c5cb Merge branch 'js/objects-larger-than-4gb-on-windows-more'
|\
| * c6a4629e32 odb: use size_t for object_info.sizep and the size APIs
| * 7a3a78cc76 packfile,delta: drop the `cast_size_t_to_ulong()` wrappers
| * 188bac14f7 pack-objects: use size_t for in-core object sizes
| * 2d83cc3f84 packfile: widen unpack_entry()'s size out-parameter to size_t
| * 1d43315b31 pack-objects(check_pack_inflate()): use size_t instead of unsigned long
| * 33afe87338 patch-delta: use size_t for sizes
| * 8ea69373a4 compat/msvc: use _chsize_s for ftruncate
* |   8cf57cbec4 Merge branch 'kw/gitattributes-typofix'
|\ \
| * | 0bf506efd4 gitattributes: fix eol attribute for Perl scripts
* | |   8d96f09e92 Merge branch 'js/objects-larger-than-4gb-on-windows'
|\ \ \
| * | | ab3810eb6f zlib: properly clamp to uLong
* | | | 95e20213fa Hopefully final batch before -rc2
* | | |   8632b5c49d Merge branch 'en/commit-graph-timestamp-fix'
|\ \ \ \
| * | | | fbcc5408fc commit-graph: use timestamp_t for max parent generation accumulator
* | | | |   619931f561 Merge branch 'dl/posix-unused-warning-clang'
|\ \ \ \ \
| * | | | | cf48887610 compat/posix.h: simplify GIT_GNUC_PREREQ() comparison
| * | | | | ffd45926dc compat/posix.h: clean up GIT_GNUC_PREREQ() and UNUSED
| * | | | | 689dc92e50 compat/posix.h: enable UNUSED warning messages for Clang
* | | | | |   621962aa7a Merge branch 'td/ls-files-pathspec-prefilter'
|\ \ \ \ \ \
| * | | | | | 3f5203eeb4 ls-files: filter pathspec before lstat
| | |_|_|_|/
| |/| | | |
* | | | | |   0c706d5092 Merge branch 'ta/doc-config-adoc-fixes'
|\ \ \ \ \ \
| * | | | | | 4fa2c6e045 doc: git-config: escape erroneous highlight markup
| * | | | | | 042221cccb doc: config/sideband: fix description list delimiter
| * | | | | | 3eb61fda62 doc: config: terminate runaway lists
* | | | | | |   49cb068fb2 Merge branch 'jc/t1400-fifo-cleanup'
|\ \ \ \ \ \ \
| * | | | | | | e8f12e0e95 t1400: have fifo test clean after itself
* | | | | | | |   b4970f8448 Merge branch 'td/describe-tag-iteration'
|\ \ \ \ \ \ \ \
| * | | | | | | | 55088ac8a4 describe: limit default ref iteration to tags

    

Chaque voie se prolonge vers le bas jusqu'au commit à partir duquel la branche a été créée. Les messages de commit sont ainsi relégués vers la droite, ce qui complique la lecture. Le problème devient particulièrement ingérable lorsque la largeur de l'écran du terminal est atteinte.

Git 2.55 ajoute une nouvelle option (--graph-lane-limit=<n>) pour limiter le nombre de voies dessinées. Toutes les voies au-delà de la limite sont remplacées par une marque de troncature ~ afin d'indiquer clairement que le graphe a été tronqué :

      git log --graph --graph-lane-limit=5

    

En utilisant cette option pour les 30 mêmes commits que ci-dessus, nous obtenons le résultat suivant :

      * 26d8d94e94 A few more topics before -rc2
*   02bb39c5cb Merge branch 'js/objects-larger-than-4gb-on-windows-more'
|\
| * c6a4629e32 odb: use size_t for object_info.sizep and the size APIs
| * 7a3a78cc76 packfile,delta: drop the `cast_size_t_to_ulong()` wrappers
| * 188bac14f7 pack-objects: use size_t for in-core object sizes
| * 2d83cc3f84 packfile: widen unpack_entry()'s size out-parameter to size_t
| * 1d43315b31 pack-objects(check_pack_inflate()): use size_t instead of unsigned long
| * 33afe87338 patch-delta: use size_t for sizes
| * 8ea69373a4 compat/msvc: use _chsize_s for ftruncate
* |   8cf57cbec4 Merge branch 'kw/gitattributes-typofix'
|\ \
| * | 0bf506efd4 gitattributes: fix eol attribute for Perl scripts
* | |   8d96f09e92 Merge branch 'js/objects-larger-than-4gb-on-windows'
|\ \ \
| * | | ab3810eb6f zlib: properly clamp to uLong
* | | | 95e20213fa Hopefully final batch before -rc2
* | | |   8632b5c49d Merge branch 'en/commit-graph-timestamp-fix'
|\ \ \ \
| * | | | fbcc5408fc commit-graph: use timestamp_t for max parent generation accumulator
* | | | |   619931f561 Merge branch 'dl/posix-unused-warning-clang'
|\ \ \ \ \
| * | | | ~ cf48887610 compat/posix.h: simplify GIT_GNUC_PREREQ() comparison
| * | | | ~ ffd45926dc compat/posix.h: clean up GIT_GNUC_PREREQ() and UNUSED
| * | | | ~ 689dc92e50 compat/posix.h: enable UNUSED warning messages for Clang
* | | | | ~ 621962aa7a Merge branch 'td/ls-files-pathspec-prefilter'
|\ \ \ \ \~
| * | | | ~ 3f5203eeb4 ls-files: filter pathspec before lstat
| | |_|_|_~
| |/| | | ~
* | | | | ~ 0c706d5092 Merge branch 'ta/doc-config-adoc-fixes'
|\ \ \ \ \~
| * | | | ~ 4fa2c6e045 doc: git-config: escape erroneous highlight markup
| * | | | ~ 042221cccb doc: config/sideband: fix description list delimiter
| * | | | ~ 3eb61fda62 doc: config: terminate runaway lists
* | | | | ~ 49cb068fb2 Merge branch 'jc/t1400-fifo-cleanup'
|\ \ \ \ \~
| * | | | ~ e8f12e0e95 t1400: have fifo test clean after itself
* | | | | ~ b4970f8448 Merge branch 'td/describe-tag-iteration'
|\ \ \ \ \~
| * | | | ~ 55088ac8a4 describe: limit default ref iteration to tags

    

Cette option n'a de sens qu'avec --graph. La valeur par défaut est 0, ce qui signifie qu'il n'y a aucune limite ; les valeurs nulles ou négatives sont traitées de la même manière, tout comme le fait --max-parents.

Cette fonctionnalité a été soumise par Pablo Sabater.

Évolution de Rust dans le code source de Git

En mars 2025, avec la sortie de Git 2.49, le premier code Rust a été ajouté au code source de Git. Des liaisons Rust ont été ajoutées pour permettre au code Rust d'appeler libgit. Mais aucune partie de ce code Rust n'était utilisée par les binaires de Git.

En novembre 2025, dans Git 2.52, le premier code de production Rust a été introduit dans Git. Une implémentation Rust du sous-système varint a alors été ajoutée. Ce code est compilé de manière facultative si le compilateur Rust est disponible ; dans le cas contraire, c'est l'implémentation C qui est utilisée. Il s'agissait d'un ballon d'essai destiné aux distributeurs, afin qu'ils commencent à préparer leurs outils en vue d'une release de Git qui finirait par exiger Rust.

Plus tôt cette année, dans la release 2.54, davantage de code Rust a été ajouté au code source avec l'introduction du type ObjectID. Celui-ci a été ajouté dans le cadre des efforts visant à mettre en œuvre une interopérabilité entre SHA-1 et SHA-256.

Jusqu'à cette release, les deux systèmes de build Make et Meson revenaient gracieusement à l'implémentation C si le compilateur Rust était introuvable. Avec cette release v2.55, le compilateur Rust est requis, sauf si vous le désactivez explicitement dans le système de build.

Veuillez noter que cela n'affecte pas les utilisateurs de Git. Cela concerne uniquement ceux qui effectuent un build de Git à partir de la source. Si vous effectuez un build de Git et que vous ne souhaitez pas utiliser Rust, désactivez-le avec l'une de ces commandes :

      # Meson
meson configure -Drust=disabled

# Makefile
make NO_RUST=YesPlease

    

L'intégration de Rust dans Git est un effort continu (et inachevé) porté par la communauté, réparti sur plusieurs releases. Il est impossible de l'attribuer à une seule personne, mais brian m. carlson, Patrick Steinhardt, Ezekiel Newren et Calvin Wan figurent parmi les contributeurs les plus marquants.

git-grep(1) et git-cherry(1) plus rapides dans les clones partiels

git-clone(1) dispose d'une fonctionnalité de clone partiel. Celle-ci permet à l'utilisateur d'appliquer un filtre aux éléments envoyés depuis le serveur. En pratique, c'est l'option --filter. Exemple :

      git clone --filter=blob:none <remote>

    

Le dépôt est cloné, mais tous les blobs sont exclus (c'est-à-dire le contenu des fichiers de l'arborescence). Le clonage en est sensiblement accéléré, mais avec un inconvénient : Git doit télécharger les blobs ultérieurement lorsque d'autres commandes lisant le contenu des fichiers sont utilisées. Et certaines commandes peuvent nécessiter de nombreux blobs manquants.

git-grep(1) est l'une de ces commandes, car elle recherche dans le contenu des fichiers. Pour ce faire, elle doit évidemment disposer de ces fichiers. Imaginez que vous souhaitez rechercher le mot « TODO » 100 commits en arrière dans l'historique :

      git grep TODO HEAD~100

    

Cette commande résout le commit HEAD~100 ainsi que les arborescences qui lui sont associées. Mais ces arborescences peuvent pointer vers des blobs qui ne sont pas encore téléchargés. Auparavant, chaque blob était téléchargé séparément. Git 2.55 propose une amélioration : les téléchargements de blobs sont regroupés en un seul aller-retour de négociation avec le serveur.

Ce regroupement est désormais implémenté à la fois pour git-grep(1) et git-cherry(1).

Cette modification a été soumise par Elijah Newren.

Pour en savoir plus

Cet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git pour cette dernière release. Vous pouvez en apprendre davantage dans l'annonce de release officielle du projet Git. Consultez également nos articles de blog précédents sur les releases de Git pour découvrir d'autres contributions des membres de l'équipe GitLab.