IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Git 2.26.0 est disponible avec le protocole de transport v2 par défaut
Et une mise à jour de la sous-commande git sparse-checkout

Le , par Bill Fassinou

824PARTAGES

5  0 
Git, le logiciel de gestion de version décentralisé open source à une nouvelle mouture, la version 2.26.0. La nouvelle version de Git apporte de nouvelles fonctionnalités, des corrections de bogues, mais aussi quelques améliorations. Git utilise désormais le protocole de transport v2, il y a plus de coloration dans CLI et la fonction git name-riv consomme à présent moins de mémoire. Git 2.26.0 apporte également l’autocomplétion des sous-commandes dans Bash/CLI. Voici ci-dessous un aperçu des changements notables dans cette nouvelle version de Git.

Transport V2 (Version Two) devient le protocole par défaut

Le protocole de transport v2 a été introduit dans Git en 2018. Il est à présent le protocole par défaut. En effet, selon la note de version de Git 2.26.0, le plus gros problème avec l'ancien protocole est que le serveur listait immédiatement toutes les branches, balises et autres références dans le dépôt avant que le client n'ait la possibilité d'envoyer quoi que ce soit. Pour certains référentiels, cela pouvait signifier l'envoi de mégaoctets de données supplémentaires, alors que l’utilisateur demandait seulement à connaître la branche principale du référentiel.

Le protocole v2 résout ce problème. Il commence par la demande du client et fournit un moyen pour le client de dire au serveur quelles sont les références qu’il veut avoir. L'extraction d'une seule branche ne demandera que cette branche, alors que la plupart des clones ne demanderont que les branches et les balises. Cela peut sembler être tout, mais les référentiels des serveurs peuvent stocker d'autres références (comme la tête de chaque requête pull ouverte dans le référentiel depuis sa création). Ceci ne nécessite aucun effort de votre part.


D’après la note de version de Git 2.26.0, grâce à une conception intelligente, tout client qui utilise le nouveau protocole peut travailler de manière transparente avec les anciens et les nouveaux serveurs, et revenir au protocole original si le serveur ne le prend pas en charge. La seule raison du délai entre l'introduction du protocole et sa mise en place par défaut était de permettre aux premiers utilisateurs de rechercher les bugs.

Mises à jour de git sparse-checkout

git sparse-checkout est une nouvelle sous-commande récemment introduite dans Git. Selon la note de version, les sparse-checkouts sont un moyen permettant de ne faire vérifier qu'une seule partie de votre dépôt à la fois. Par exemple, considérons que vous travaillez dans un monorepo, et que vous n'avez besoin que du répertoire client/macos, et de tout ce qu'il contient. Vous ne voulez probablement pas passer du temps à télécharger de vieux blogues en dehors de ce répertoire si vous n'allez jamais les utiliser. Alors, comment faut-il procéder ?

Premièrement, il demande au serveur de n'envoyer que des objets d'arborescence et de commit au lieu de tous les blobs. Ensuite, il dit au client de s'attendre à ce que certains objets du dépôt soient manquants, et de demander au serveur de lui envoyer l'un de ces objets si nécessaire, par exemple pour un checkout. Pour corriger cela, Git 2.26 dispose maintenant d'un nouveau mode d'ajout de git sparse-checkout qui vous permet d'ajouter de nouvelles entrées de répertoire une à la fois.

git grep est maintenant plus rapide

git grep se comporte comme grep, mais fonctionne dans votre dépôt Git. Vous pouvez greffer le contenu de votre dépôt, mais vous pouvez aussi greffer les révisions historiques. git grep utilise plusieurs threads pour améliorer ses performances lors de l'analyse du contenu de votre arborescence de travail. Cependant, dans les versions précédentes de Git, en raison de certains détails du mécanisme de stockage des objets de Git, git grep évitait d'utiliser plusieurs threads lors de l'examen des révisions historiques. Cela est à présent corrigé.

Dans Git 2.26, cette limitation n'existe plus. La couche de stockage d'objets supporte maintenant l'accès simultané. Désormais, vous pouvez profiter de tous les avantages de git grep --threads, quel que soit l'endroit où vous effectuez votre recherche. Et comme les --threads correspondent par défaut au nombre de cœurs sur votre poste de travail, vous n'avez même pas besoin de taper --threads. Par ailleurs, Git 2.26 dispose d’autres fonctionnalités comme :

  • amélioration de l'autocomplétion Bash/CLI pour les différentes sous-commandes ;
  • un crochet fsmonitor-watchman amélioré pour éviter les situations de concurrence dans la version précédente ;
  • pour la coloration du CLI, les sept couleurs ont maintenant des options de variantes de couleurs plus vives ;
  • la nouvelle base de Git utilise maintenant le back-end de « fusion » par défaut ;
  • il y a moins d'encombrement de la mémoire et de meilleures performances pour la fonctionnalité git name-rev ;
  • etc.

Source : Note de version de Git 2.26.0

Et vous ?

Qu'en pensez-vous ?

Voir aussi

GitHub publie un nouvel outil nommé git-sizer afin d'aider les mainteneurs à optimiser leurs dépôts

La version 2.9 de Git est maintenant disponible. Cette nouvelle version vient notamment avec une heuristique améliorée pour le moteur git diff

Git, le système distribué de gestion de versions, vient de passer à la version 2.23 et propose deux commandes expérimentales pour réduire l'usage de la commande « git checkout »

Une erreur dans cette actualité ? Signalez-nous-la !