+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    février 2017
    Messages
    474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 474
    Points : 15 803
    Points
    15 803

    Par défaut La version 2.17 de Git, l’outil open source de gestion de versions, est disponible

    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

    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.

    Nom : git-logo_bv0ydu.jpg
Affichages : 4443
Taille : 27,8 Ko

    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.

    Nom : find object.png
Affichages : 4366
Taille : 30,3 Ko

    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.

    Nom : color-moved.png
Affichages : 4453
Taille : 71,7 Ko

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre confirmé
    Profil pro
    Inscrit en
    août 2008
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2008
    Messages : 176
    Points : 516
    Points
    516

    Par défaut

    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...

  3. #3
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    septembre 2007
    Messages
    7 107
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2007
    Messages : 7 107
    Points : 22 513
    Points
    22 513

    Par défaut

    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.

  4. #4
    Membre extrêmement actif
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 576
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 576
    Points : 2 614
    Points
    2 614

    Par défaut

    Très très bon outil Git
    Rem: il n'y a pas que Github comme répo, il y a aussi Gitlab, Bitbucket.
    Si la réponse vous a aidé, pensez à cliquer sur +1

Discussions similaires

  1. Réponses: 0
    Dernier message: 15/03/2018, 09h24
  2. Réponses: 0
    Dernier message: 25/02/2015, 13h47
  3. Le framework open source Django sort en version 1.7
    Par Hinault Romaric dans le forum Django
    Réponses: 9
    Dernier message: 13/09/2014, 11h31
  4. Réponses: 2
    Dernier message: 21/06/2012, 23h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo