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 !

La version 2.17 de Git, l'outil open source de gestion de versions, est disponible
Et intègre de nouvelles fonctionnalités dont une d'accélération

Le , par Patrick Ruiz

460PARTAGES

12  0 
L’équipe du projet Git annonce la disponibilité de la version 2.17 de Git, l’outil open source de gestion de versions des logiciels. GitHub, la plateforme d’hébergement et de gestion de développement de logiciel, s’est fait le relais de l’information.

Cette version intègre des correctifs relatifs à des comportements erratiques de certaines commandes disponibles. La liste est assez longue et comprend git status, git commit, git add – des commandes de base de l’outil – qui causaient des soucis dans la version 2.16 de l’outil de gestion de versions. Le détail à ce propos dans la note de version détaillée. Avec Git 2.17, il faut également s’attendre à un minimum de trois nouvelles fonctionnalités qui sautent à l’œil : coloration de code déplacé, accélération et recherche d’objets.


Git 2.17 est synonyme d’accès rapide à l’information. Cette version est en effet dotée d’une fonctionnalité de recherches d’objets au sein de l’historique intégré au logiciel. Les utilisateurs de l’outil de gestion de versions disposent désormais de la commande --find-object à utiliser en tandem avec un hash d’objet pour faire apparaitre tous les nœuds de l’arborescence contenant ce dernier – ou une modification – au sein de l’arborescence. Plutôt intéressant puisque la fonctionnalité retourne les chemins d’accès.


L’un des problèmes auquel les développeurs qui travaillent sur des projets avec un nombre de fichiers très important est que le temps de réponse de la commande git status augmente considérablement. Git 2.17 vient avec watchman pour apporter réponse à cet état de choses en court-circuitant l’appel système status() et ses accès en lecture répétés sur le disque dur.

L’outil permet de rendre la charge de travail liée au suivi des modifications proportionnelle au nombre de fichiers modifiés en s’appuyant sur le système d’exploitation lui-même, ce qui raccourcit les temps d’attente. Watchman – proposé par Facebook sous licence Apache 2.0 – est disponible sur Windows (7 et versions ultérieures), Linux et macOS (10.X). Enfin, rien de tel qu’un bon visuel pour introduire à la dernière fonctionnalité phare de cette version.


Avec Git 2.17, les développeurs disposent de la commande --color-moved. À utiliser dans les cas de passage en revue de commits pour savoir quelles sections de codes ont fait l’objet de déplacements. En guise de résultat, la commande renvoie une version du commit colorée en conséquence. L’équipe du projet précise que les couleurs sont configurables. Dans cet exemple, le bleu représente les portions de code déplacées d’une zone à l’autre du texte tandis que le vert et le rouge mettent les modifications au sein de ces blocs en lumière.

Grosso modo, c’est GitHub qui, en plus de l’outil git-sizer annoncé le mois passé, s’enrichit de fonctionnalités qui étendent encore plus l’arsenal du développeur. Toutefois, attention, car ceux qui ont fait le choix de plateformes alternatives comme gitweb, Gitstack, Gitlab, etc. peuvent également profiter de ces nouveautés. À chacun ses préférences.

Source

Blog GitHub

Et vous ?

Que pensez-vous de ces nouvelles fonctionnalités ?

Laquelle vous paraît la plus utile ?

Voir aussi

GitHub veut développer un nouvel éditeur de texte multiplateforme et ultraperformant basé sur Electron, Xray est encore un projet expérimental
GitHub : des chercheurs estiment que plus de la moitié des codes écrits en Java, Python, C/C++ et JavaScript sont dupliqués

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

Avatar de Obsidian
Modérateur https://www.developpez.com
Le 08/04/2018 à 21:03
Citation Envoyé par captaindidou Voir le message
Comment des commandes de base peuvent-elles être encore erratiques à ce stade du cycle de vie ? C'est impensable...
Je pense qu'il s'agit d'un raccourci un peu rapide. Je n'ai rien vu « d'erratique » à proprement parler dans le blog et de toutes façons, il s'agit de correctifs depuis la version 2.16 (soit la précédente), et pas de quelque chose qui serait resté en suspens depuis la sortie de Git en 2005 (13 ans ce mois-ci tout de même). En ce qui concerne les notes de versions fournies dans le dépôt lui-même, on voit toutes sortes de choses, dont pas moins de 46 entrées dans la section bugfixes en particulier. Celles qui évoquent les commandes en question sont celles-ci :

Citation Envoyé par Relnotes 2.17
* "git status" after moving a path in the working tree (hence making
it appear "removed" and then adding with the -N option (hence
making that appear "added" detected it as a rename, but did not
report the old and new pathnames correctly.

[…]

* "git commit --fixup" did not allow "-m<message>" option to be used
at the same time; allow it to annotate resulting commit with more
text.

[…]

* "git add -p" was taught to ignore local changes to submodules as
they do not interfere with the partial addition of regular changes
anyway.

[…]

* "git add" files in the same directory, but spelling the directory
path in different cases on case insensitive filesystem, corrupted
the name hash data structure and led to unexpected results. This
has been corrected.
(merge c95525e90d bp/name-hash-dirname-fix later to maint).

[…]

* "git commit" used to run "gc --auto" near the end, which was lost
when the command was reimplemented in C by mistake.
(merge 095c741edd ab/gc-auto-in-commit later to maint).

… et en fait, on s'aperçoit que toutes les commandes ou presque sont concernées dans le reste de la liste. Donc il s'agit de correctifs ordinaires même à ce stade du développement, voire même de comportements indésirables dans certains cas, plus que de réels bugs.

Par ailleurs, en lisant en diagonale le blog en question, on trouve d'autres infos intéressantes sur lesdites commandes. On peut d'abord y lire que cette version bénéficie de « features and bugfixes » (donc correctifs ET fonctionnalités) de la part d'une soixantaine de collaborateurs.

Ensuite, en faisant une petite recherche avec le mot « status », on arrive tout de suite au paragraphe qui traite de cette commande en particulier, où il est en fait question de l'accélérer (plus encore qu'elle l'est déjà). Il y est expliqué en substance que pour vérifier si un fichier suivi a besoin d'être contrôlé ou non, Git commence par appeler stat() (qui est l'appel système qui sert à obtenir les méta-informations d'un fichier, notamment sa taille et sa date de dernière modification) et que s'il est avéré que le fichier n'a pas bougé depuis la dernière fois (car cette information peut aussi être indisponible, auquel cas il faut faire le contrôle), eh bien il s'épargne tout simplement cette peine, avec raison.

Ça permet de ré-insister sur un point assez notable, par rapport à un DVCS incrémental qui stocke ses diffs consécutivement dans un fichier : le système d'objets permet à Git de re-déléguer au système de fichiers tout ce qui aurait dû le rester depuis toujours : disponibilité, intégrité du contenu, sauvegarde, mise en cache et indexation pour une récupération rapide (par rapport à un parcours séquentiel de l'historique des modifs dans le cas d'un fichier unique, par exemple). Et en ce sens, le choix du système de fichiers sur lequel on va ouvrir tous les dépôts va avoir un impact non-négligeable sur les performances d'un service Git déployé à grande échelle. D'ailleurs, en 2005, dans une de ses présentations en public, Linus se plaignait ouvertement des performances de celui de Windows à ce sujet. Ça a dû changer depuis… Ça va aussi être particulièrement vrai si l'on utilise un système de fichiers en réseau ou un lecteur partagé. Même si, là encore, l'architecture distribuée de Git est justement conçue pour éviter d'avoir à le faire.

Ce qui est expliqué dans le blog à ce sujet, donc, c'est qu'il est maintenant possible depuis 2.16 (la précédente version) de mettre en place un hook pour déléguer cette tache à un programme qui en aura la charge et auquel Git se fiera, plutôt qu'appeler lui-même stat() à tout bout de champ, ce qui permet de faire de substantielles optimisations dans un environnement industriel. Et à dire vrai, il est dit que l'interface est universelle et peut être utilisée avec n'importe quoi mais qu'elle a surtout été mise en place pour permettre l'utilisation de watchman.

Autre chose intéressante : on y apprend qu'il y a bien un plan de migration en train d'être mis en place pour quitter SHA1 au besoin, suite à la récente découverte d'une méthode de collision artificielle. Si cela ne remet en aucune façon en cause l'architecture de Git elle-même et que le logiciel pourrait s'appuyer a priori sur n'importe quelle fonction de hachage rendant les mêmes services, migrer un dépôt de l'une vers l'autre, faire un plan de transition et coordonner tous les dépôts décentralisés qui, par nature, sont indépendants les uns des autres est une vraie gageure (et un authentique projet d'ingénierie, à mon avis). C'est une bonne chose de savoir qu'un groupe de travail est d'ores et déjà en place pour plancher sur cette question.
5  0 
Avatar de captaindidou
Inactif https://www.developpez.com
Le 07/04/2018 à 21:58
Citation Envoyé par Patrick Ruiz Voir le message


Cette version intègre des correctifs relatifs à des comportements erratiques de certaines commandes disponibles. La liste est assez longue et comprend git status, git commit, git add – des commandes de base de l’outil – qui causaient des soucis dans la version 2.16 de l’outil de gestion de versions. Le détail à ce propos dans la note de version détaillée.
Comment des commandes de base peuvent-elles être encore erratiques à ce stade du cycle de vie ? C'est impensable...
1  0 
Avatar de hotcryx
Membre extrêmement actif https://www.developpez.com
Le 09/04/2018 à 10:10
Très très bon outil Git
Rem: il n'y a pas que Github comme répo, il y a aussi Gitlab, Bitbucket.
1  0