La version 2.20.0 de Git, logiciel de gestion de versions décentralisé, vient tout juste d’être étiquetée par Junio Hamano, le mainteneur. Elle contient comme toujours un nombre important d’améliorations, même si elles ne sont pas forcément visibles par la plupart des utilisateurs (certaines nouveautés sont détaillées en seconde partie de la dépêche).
Pour être tenu au courant de l’actualité Git, il y a Git Rev News, une lettre d’actus mensuelle qui contient pas mal d’infos en tout genre liées à Git (Git Rev News est éditée depuis presque quatre ans par un petit groupe de développeurs et de fans dont je fais partie).
Il y a aussi prochainement la conférence Git Merge à Bruxelles le 1er février prochain, juste avant le FOSDEM (2 et 3 février). Oui, c’est au même endroit, appelé The EGG Brussels, que la Git Merge 2017 qui avait aussi lieu juste avant le FOSDEM. Comme d’habitude, le jour précédant la Git Merge proprement dite (donc le 31 janvier), des workshops sont proposés et, en parallèle, il y a un Git Contributor Summit auquel tous les développeurs de Git ou d’un logiciel lié à l’écosystème de Git sont invités.
Revenons sur les nouveautés de la version 2.20.0. En particulier sur git rebase, qui est maintenant complètement (ou presque) réécrit en C (bien qu’il soit toujours possible d’utiliser l’ancienne version en configurant rebase.useBuiltin à false).
Une autre amélioration, à laquelle j’ai aussi un peu participé, est un ensemble d’options de stockage appelé delta-islands initialement développé par GitHub il y a plusieurs années. Cela permet d’améliorer significativement les performances lorsque l’on stocke tous les divergences (forks) d’un dépôt (repo) dans le même dépôt sous‐jacent. GitLab travaille actuellement à cela en utilisant justement les delta-islands, suite à une demande de Drupal.
Aller plus loin
- [ANNOUNCE] Git v2.20.0 (307 clics)
- Counting Objects by GitHub (104 clics)
- Object Deduplication by GitLab (140 clics)
- Drupal Moving to GitLab (104 clics)
- Git Rev News Archive (159 clics)
- Git Merge Conference (96 clics)
- FOSDEM 2019 (95 clics)
- Git Contributor Summit (78 clics)
# rebase
Posté par barmic . Évalué à 7.
Comment c'était avant ? Est-ce que c'est uniquement une histoire de performance ? Pourquoi vouloir le désactiver (uniquement pour d'éventuelles régressions ?) ? Si ce n'est qu'une question de performance comment c'était avant quel gain on peut attendre (dès quelques commits ou bien uniquement sur des historiques immenses) ?
[^] # Re: rebase
Posté par Christian Couder (site web personnel) . Évalué à 6.
Avant, dans la 2.19.2 et les versions précédentes, il restait plusieurs grosses parties de
git rebaseen Shell:Ce sont des étudiants pour le Google Summer of Code 2018 qui ont porté ces scripts en C.
En fait depuis 2008, il y a eu de nombreux efforts par des développeurs et/ou des étudiants pour le Google Summer of Code (notamment en 2008 et 2010) pour en porter une partie, car initialement tout était en Shell.
[^] # Re: rebase
Posté par barmic . Évalué à 3.
Ok donc le gain est surtout pour la portabilité je présume
[^] # Re: rebase
Posté par Francois Revol (site web personnel) . Évalué à 4. Dernière modification le 09 décembre 2018 à 23:16.
de performance aussi (tout compiler dans un seul binaire évite de lancer de nombreuses commandes, et donc des fork+exec, et plein d'autres choses).
[^] # Re: rebase
Posté par barmic . Évalué à 3. Dernière modification le 10 décembre 2018 à 00:16.
Ça c'est de l'imagination. Est-ce que ça a un impact sensible ? En lisant vite fait le code shell, il me semble que les parties les plus coûteuses (celles qui manipulent les objets git) sont déjà écrites en C. Je ne suis pas sûr que le coût des fork/exec et des io (il y a pleins de redirections) soit significatif. C'est pour ça que j'ai posé ma première question.
[^] # Re: rebase
Posté par Christian Couder (site web personnel) . Évalué à 6. Dernière modification le 10 décembre 2018 à 04:56.
Effectivement les parties les plus coûteuses en terme de performances, sont celles qui ont été portées le plus tôt historiquement en C. Néanmoins, sous Windows en particulier où le fork/exec est assez coûteux, cela apporte quand même des petits gains de performance de tout porter en C.
Les autres raisons pour lesquelles l'élimination du Shell dans les commandes Git est intéressante sont de faciliter le portage et l'installation de Git sur des systèmes où il n'y a pas forcement de Shell de type sh installé par défaut, et surtout de faciliter la maintenance (amélioration, débogage, re-factorisation, réutilisation, …) du code commun à de nombreuses commandes.
[^] # Re: rebase
Posté par cosmocat . Évalué à 2.
Pour ce que ça vaut comme fiabilité (sous Windows) :
https://github.com/git-for-windows/build-extra/pull/203#issuecomment-416610675
[^] # Re: rebase
Posté par benoar . Évalué à 10.
Moi c'est ça que j'adore avec git, c'est qu'il est vraiment fait selon la philosophie Unix que pourtant beaucoup remettent en cause aujourd'hui : ses morceaux sont des exécutables implémentés dans des langages différents (il y a du C, du shell, du perl, de ce que j'ai vu) et interagissent par fork + entrées/sorties standard (ou plus), dans des formats ouverts et documentés. La persistance est gérée par fichier (allez voir comment le "git rebase" gère une interruption — même un plantage — de son flow : il écrit une « todo-list » dans un fichier et la met à jour après chaque application de patch !), dans des formats encore une fois bien définis : ce sont les formats (de fichier et de protocole — cf. git-fast-import(1) par exemple) qui guident l'implémentation, plutôt que le code, selon une pratique voulue par Torvalds.
Bref, on se fout de moi quand je dis que j'écris encore pas mal de shell pour des outils « sérieux », et j'étais bien content de voir (il y a déjà quelques années de cela) que git — qui est une référence pour moi et pour beaucoup d'autres, j'espère — l'utilise encore pas mal, même s'il est remplacé pour des raisons de performance seulement (et de portabilité, oui, mais ça je m'en fout).
[^] # Re: rebase
Posté par asky . Évalué à 2. Dernière modification le 11 décembre 2018 à 23:47.
Dans un cadre professionnel, je confirme et suis souvent surpris du fait qu'un code Bash écrit des années plus tôt s'exécute sans erreur là où les autres outils ou langages ont évolué et de ce fait "cassés" des scripts simples (modification de syntaxes, ajout/suppression de sucres, changement/disparition de librairie, modification de comportement des objets conteneurs ou des compilateurs/environnement d'exécution).
Pour revenir au sujet de Git,
il manque peut-être à Git une interface semi-graphique. Je pense à la commande htop dans une console qui permet d'appeler des options par raccourcis clavier et aussi en clic souris (oui, dans une console).
Ce serait une plus-value en terme de confort pour l'utilisateur… plutôt qu'une recherche de performance qui sera comblée de toute façon par l'évolution de la puissance de nos machines…
Vous l'aurez deviné, j'utilise principalement Git en ligne de commande… ;)
[^] # Re: rebase
Posté par barmic . Évalué à 7.
Comme tig par exemple ?
[^] # Re: rebase
Posté par asky . Évalué à 1.
Merci pour la référence.
Juste ce qu'il me fallait.
[^] # Re: rebase
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
Un autre avantage est que du coup ce code va pouvoir être mis dans la libgit, et donc être accessible aux outils qui utilisent cette lib plutôt que de lancer git en ligne de commande: intégration dans les IDE, dans les forges qui pourront facilement permettre un rebase depuis une interface web, etc.
Les dépôts git ne sont pas toujours manipulés exclusivement depuis l'outil en ligne de commande, et donc, se traîner des scripts bash n'est pas toujours pratique ni approprié dans d'autres contextes.
Cela permet aussi de faire un pas de plus vers un gi qui peut s'exécuter sous Windows sans avoir préalablement besoin d'installer bash.
[^] # Re: rebase
Posté par Christian Couder (site web personnel) . Évalué à 2.
Je ne sais pas si tu parles de libgit.a qui est créé lors de la compilation de Git, ou si tu parles de libgit2.
libgit2 est un projet différent, qui a été initialement créé à partir du code de Git, mais qui a pas mal divergé depuis. Ce n'est pas sûr qu'ils arrivent bientôt à intégrer ou réimplémenter tout le
git rebase.libgit.a par contre n'est pas très adapté pour être réutilisé dans différents outils.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.