Git 2.56 sécurise la résolution des conflits et accélère la maintenance des dépôts

Git 2.56.0 est disponible avec plusieurs changements destinés à rendre la résolution des conflits plus sûre et la maintenance des dépôts plus évolutive. Cette version introduit un mode d’indexation ciblé pour les conflits résolus, raccourcit certaines recherches de bases de fusion et lève deux restrictions qui limitaient l’usage des recompressions par parcours des chemins sur les serveurs de dépôts.

Une indexation des conflits plus sûre

Le nouveau mode `git add --resolved` n’indexe que les chemins actuellement signalés comme non fusionnés. Avant de modifier l’index, Git vérifie dans les fichiers ordinaires sélectionnés la présence éventuelle de marqueurs de conflit résiduels. S’il en trouve, aucun de ces fichiers n’est indexé. Les modifications suivies sans rapport avec le conflit restent donc intactes, ce qui réduit le risque d’inclure accidentellement du travail local avec des commandes plus larges comme `git add -u` ou `git add -A`.

Les développeurs peuvent fournir un pathspec pour limiter l’opération. Les suppressions résolues et les conflits binaires peuvent toujours être indexés, puisqu’ils ne contiennent pas de marqueurs textuels. En revanche, le nouveau mode ne peut pas être combiné avec les options plus générales `--update` ou `--all`.

Une sortie plus rapide de la recherche de bases de fusion

Git suit désormais la présence de commits exclusifs à chacun des deux côtés dans la file de parcours des bases de fusion. Dès qu’un côté exclusif est épuisé, la recherche peut s’arrêter, car aucun autre point de rencontre commun ne peut apparaître. Le mécanisme conserve néanmoins la prise en charge des historiques possédant plusieurs bases de fusion valides.

GitHub rapporte des gains importants sur les dépôts évalués. Dans un monorepo, un cas est passé de 0,68 seconde à 0,01 seconde. Les mesures en production ont aussi relevé de nombreuses opérations environ 70 fois plus rapides dans un grand monorepo, ainsi qu’une amélioration moyenne d’environ 20 fois dans un autre. Pour le noyau Linux, un cas est passé de 167 441 étapes de parcours à 3 887.

Des recompressions côté serveur moins volumineuses

Les recompressions par parcours des chemins regroupent les objets selon leur emplacement dans l’arbre afin de trouver de meilleures relations delta. Dans le benchmark Fluent UI de GitHub, elles ont produit un pack de 164,4 Mo, contre 558,5 Mo pour une recompression bitmap classique, soit une réduction d’environ 71 %. Git 2.56 rend désormais cette approche compatible avec les bitmaps d’accessibilité et les îlots de deltas, supprimant deux obstacles à son adoption par les hébergeurs de dépôts.

La fonctionnalité reste désactivée par défaut. Les opérateurs de serveurs peuvent évaluer ses bénéfices en matière de stockage sans renoncer à l’énumération accélérée par bitmap ni aux règles d’isolation des îlots de deltas, mais Git n’active pas automatiquement les recompressions par parcours des chemins.

Autres évolutions des flux de travail

La version ajoute également la commande expérimentale `git history drop`, la suppression groupée des branches fusionnées, des options de nettoyage automatique pour `git bisect run` et un mode `--linearize` pour la commande expérimentale `git replay`. Les clones partiels peuvent aussi supprimer manuellement les gros blobs récupérables grâce à une recompression filtrée, mais le mécanisme ne prend actuellement en charge que les filtres `blob:limit` et exige un dépôt distant promisor.

Git 2.56 améliore aussi le suivi des renommages de `git log --follow` dans les historiques non linéaires et corrige plusieurs problèmes d’évolutivité. Parmi les exemples rapportés, un diff limité à un chemin sur un checkout de Chromium passe d’environ huit minutes à 0,07 seconde, tandis que les tests des tombstones de reftable passent d’environ 13 secondes à 0,2 seconde.

Illustration éditoriale générée par IA ; ce n’est pas une photographie documentaire.

Source: Highlights from Git 2.56