URL: https://linuxfr.org/news/sortie-de-git-2-9 Title: Sortie de git 2.9 Authors: Lucas M5oul, Matthieu Moy, Nairwolf, palm123 et Yves Bourguignon Date: 2016年06月17日T11:33:24+02:00 License: CC By-SA Tags: git, gestionnaire_de_version, sortie_version et linus_torvalds Score: 71 git 2.9 est sorti le **13 juin 2016**. Pour rappel, git est un [gestionnaire de version décentralisé](https://fr.wikipedia.org/wiki/Gestion_de_versions#Gestion_de_versions_d.C3.A9centralis.C3.A9e), originellement développé par Linus Torvalds pour versionner les sources du noyau Linux. Depuis, ce gestionnaire de version est devenu très populaire parmi les projets *open-source*, comme en témoigne le succès des plateformes basées sur cet outil, comme [GitHub](https://github.com/) ou [Gitlab](https://gitlab.com/explore/projects/trending), ainsi que les projets de toutes tailles auto-hébergés utilisant git. Dans cette dépêche nous nous proposons de revenir sur quelques-uns des changements apportés par cette version. ![Git logo](https://upload.wikimedia.org/wikipedia/commons/thumb/e/e0/Git-logo.svg/320px-Git-logo.svg.png) ---- [Notes de version](https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.9.0.txt) [Site officiel de git](https://git-scm.com/) [Annonce sur GitHub](https://github.com/blog/2188-git-2-9-has-been-released) [Journal de l’annonce sur LinuxFR](https://linuxfr.org/users/windu2b/journaux/sortie-de-git-2-9) [Article sur Makina Corpus](http://makina-corpus.com/blog/metier/2016/les-nouveautes-de-git-2.9) [Git Rev News : la lettre de la communauté Git](https://git.github.io/rev_news/) ---- # Améliorations de la commande `diff` ## Lisibilité des `diff` La relecture de `diff` est parfois rendue fastidieuse par leur côté asémantique. Le véritable changement introduit par un commit, comme par exemple l’ajout d’un bloc de code, n’apparaît pas clairement dans un diff représenté ainsi : ```diff function exemple (tab) { tab.forEach(element => { + action1(element); + }); + + tab.forEach(element => { action2(element); }); ``` Cette nouvelle version améliore le rendu des `diff` en rendant leur détection et coloration plus intelligentes (par détection des lignes vides). L’exemple précédent devient ainsi : ```diff function exemple (tab) { + tab.forEach(element => { + action1(element); + }); + tab.forEach(element => { action2(element); }); ``` Cette fonctionnalité s’active avec l’option `--compaction-heuristic` ou avec la configuration `diff.compactionHeuristic`. Cette fonctionnalité est toutefois encore expérimentale. Pour rappel dans les versions précédentes de git, dans certains cas, les `diff` pouvaient être plus clairs et générer moins de conflits par l’utilisation de l’algorithme [patience](http://alfedenzo.livejournal.com/170301.html) via l’option `--patience` ; cette possibilité est toujours présente. ## Renommages et `diff` Une autre amélioration apportée par cette version est la détection des renommages par la commande `diff` qui se fait désormais par défaut. Le comportement peut être configuré via la clé `diff.renames`. #Amélioration de la commande `log` Le format de sortie de la commande `git log` expanse désormais les tabulations en affichant le message de commit. En effet, `git log` affiche ce message avec une indentation de quatre espaces, ce qui cassait l'affichage des messages utilisant les tabulations pour l'alignement. Il est possible d'utiliser l'option `--no-expand-tabs` pour désactiver ce comportement. # Amélioration de la commande `tag` `git tag` peut désormais créer un tag annoté sans utiliser explicitement l'option `-a` (ou `-s`) lorsqu’un message d’étiquetage est donné. Une nouvelle clé de configuration `tag.forceSigneAnnotated` peut être utilisée pour que la commande crée un tag signé dans cette situation. # Tester chaque *commit* lors d’un `rebase` Pendant un rebase interactif `git rebase -i` il était déjà possible d’exécuter une commande entre deux commits en ajoutant une ligne avec le préfixe `x` ou `exec` puis la commande. On pouvait insérer une telle ligne après chaque commit avec par exemple : ```sh $ git rebase -i --exec "make test" ``` Cela ouvre plusieurs possibilités, comme lancer un jeu de tests sur chaque commit pour corriger plusieurs défauts (là où un `bisect` devrait être utilisé pour chaque défaut), compiler le code pour vérifier la syntaxe ou encore lancer du _linting_ et améliorer la qualité du code ; le `rebase` est mis en pause si la commande utilisée renvoie une erreur. Un `git rebase --continue` reprend l’opération à tout moment. L'option `--exec` (ou `-x`) est maintenant utilisable sans spécifier explicitement `-i`, ce qui permet d'économiser quelques caractères sur la commande et évite de lancer inutilement l'éditeur de texte. # Amélioration de la commande `merge` Avant cette nouvelle version, la commande `git merge` permettait par défaut de fusionner deux branches sans aucune base commune dans leurs historiques respectifs. Ce comportement par défaut créait un historique parallèle dans le projet qui fusionnait une branche d’un autre projet, faisant grossir de manière inutile l’historique du projet. Le comportement par défaut a été changé dans cette version afin de ne pas autoriser la fusion de deux branches sans rapport. Bien sûr il est toujours possible de l’autoriser via l’option `--allow-unrelated-histories` dans les rares cas où ce comportement est souhaité. Cette option a aussi été ajoutée à la commande `git pull` afin d’être passée au `merge` sous-jacent. # Améliorations dans la gestion des sous-modules ## Parallélisation Dans la version précédente, la possibilité de récupérer les sous-modules en parallèle avait été ajoutée via l’option `--jobs=` lors d’un `fetch`. Dans cette version, cette possibilité a été étendue aux opérations de clonage et de mise à jour. Si vous souhaitez toujours paralléliser ces opérations sur les sous-modules, cela se configure via la clé `submodule.fetchJobs`. ## Migration de code Afin de profiter de ce nouveau _framework_ de parallélisation, la majeure partie du code de `submodule update` a été migrée en C. D’autres parties de code concernant les sous-modules ont aussi été portées en C. La logique des commandes `git submodule` était précédemment écrite en script shell. # Amélioration de la commande `describe` La commande [`git describe --contains`](https://git-scm.com/docs/git-describe), qui donne une description d’un commit par sa position relative au tag le plus proche qui le contient, a tendance à générer un nom quelque peu sibyllin et surtout difficile à expliquer. La sortie de cette commande est composée de deux parties : 1. le tag le plus proche contenant le commit ; 2. le nombre de commit pour l’atteindre. Ce qui ressemble généralement à cette sortie : `my-tag~13`. Le problème de l’ancien comportement est que si un proche descendant du commit a été récemment taggé, alors ce nouveau tag est pris comme référence dans la sortie de la commande, à la place du tag le plus ancien qui le contenait. Dans cette version, le comportement a été revu afin d’être plus clair à interpréter. Cette commande retourne donc maintenant « la description d’un commit par rapport au tag le plus ancien (chronologiquement) qui le contient ». Par exemple, la révision `aed06b9` (qui est utilisée dans [le rapport de bug à l’origine du changement](http://thread.gmane.org/gmane.comp.version-control.git/292105/)) du noyau Linux était auparavant décrite comme `v4.6-rc1~9^2~792`, ce qui est correct au sens où cette révision est bien l’ancêtre au 792^e degré du deuxième parent de l’ancêtre au 9^e degré du tag `v4.6-rc1`, mais trompeur, car cette révision est en réalité très ancienne et la description incluant `v4.6-rc1` laissait entendre que le commit avait été introduit juste avant la version 4.6-rc1. Avec Git 2.9, le résultat est `v3.13-rc1~65^2^2~42`, et effectivement `v3.13-rc1` est le plus ancien tag postérieur à la révision.

AltStyle によって変換されたページ (->オリジナル) /