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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

GIT Discussion :

Git 2.10 est disponible


Sujet :

GIT

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2013
    Messages
    320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2013
    Messages : 320
    Points : 27 374
    Points
    27 374
    Billets dans le blog
    1
    Par défaut Git 2.10 est disponible
    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

    Deux mois après la sortie de la version 2.8 de Git, la version 2.9 du gestionnaire de versions est disponible avec un nombre important de nouvelles fonctionnalités ainsi que des corrections de bogues très attendues par certains membres de la communauté. L’équipe derrière Git met en avant des sous-modules plus flexibles et plus rapides pour cette nouvelle version du gestionnaire de versions. Avec la version 2.9, il est désormais possible d’utiliser l’option --jobs pour cloner ou mettre à jour un sous-module comme le montre la capture suivante.

    Nom : Screen Shot 2016-06-16 at 09.52.03.png
Affichages : 3388
Taille : 16,5 Ko

    Une autre nouvelle fonctionnalité relative aux modules dans la version 2.9 du gestionnaire de versions est la possibilité de spécifier la manière de cloner ces derniers. La nouvelle version de Git permet maintenant de passer les options de configuration de la ligne de commande aux sous-modules. Ce qui permet de définir notamment des variables communes à tous les sous-modules en utilisant la ligne de commande suivante : git -c http.proxy=... clone --recursive.

    Depuis la version précédente de Git, le gestionnaire de versions permettait d’utiliser, avec Git LFS, l’option -c pour rendre plus rapide la création de la branche initiale. De la même manière, la version 2.9 permet maintenant de passer l’option --shallow-submodules à la commande git clone pour effectuer un clonage faible de tous les sous-modules.

    La version 2.9 de Git améliore également la façon dont les différences entre les versions d’un fichier sont présentées au fur et à mesure que des modifications lui sont apportées. Cette fonctionnalité très utile de Git qui permet de savoir quelle partie a été ajoutée à un fichier, quelle partie en a été supprimée ou encore quelle autre partie en a été modifiée. Cependant, la manière de les présenter pouvait être confuse quelques fois avec les anciennes versions de Git.

    Nom : Screen Shot 2016-06-16 at 09.55.05.png
Affichages : 3406
Taille : 37,4 Ko

    La nouvelle version du gestionnaire de versions améliore la présentation de ces différences entre les versions du même fichier grâce à une nouvelle heuristique qui lui permet de détecter les lignes vides séparant les grands blocs de code et puis de décaler ces derniers vers le haut jusqu’à atteindre une ligne non vide. La capture suivante montre la différence avec la version précédente de l’heuristique utilisée par le moteur de git diff.

    Nom : Screen Shot 2016-06-16 at 09.56.13.png
Affichages : 3315
Taille : 36,8 Ko

    Cette nouvelle heuristique reste cependant à une phase expérimentale et peut être amenée à évoluer au fil du temps. Pour le moment le soin est laissé à l’utilisateur de l’activer en exécutant la commande --compaction-heuristic dans le terminal ou en ajoutant la ligne diff.compactionHeuristic dans le fichier de configuration de git.

    En plus de la coloration syntaxique qu’offre Git, la nouvelle version vient aussi avec des filtres permettant de personnaliser davantage les sorties de la commande diff. En effet, la commande diff-highlight permet de mettre en surbrillance la partie modifiée comme le montre la capture suivante.

    Nom : Screen Shot 2016-06-16 at 09.57.19.png
Affichages : 3175
Taille : 32,4 Ko

    La fonction rebase a également été améliorée avec la possibilité d’y associer maintenant l’option -x, ce qui permet d’ajouter la commande au début de chaque validation pour ne pas avoir à réécrire plusieurs fois la commande exec make test. À noter également pour cette nouvelle version de Git, la possibilité de mapper les utilisateurs avec des identifiants Git ainsi que la possibilité de définir des chemins personnalisés pour les modules.

    Source : github.com

    Et vous ?

    Que pensez-vous de cette nouvelle version de Git ?

    Voir aussi

    le forum Logiciels Libres et Open Source

  2. #2
    Chroniqueur Actualités

    Homme Profil pro
    Webmaster
    Inscrit en
    Janvier 2014
    Messages
    1 089
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Webmaster
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2014
    Messages : 1 089
    Points : 26 557
    Points
    26 557
    Par défaut Git 2.10 est disponible
    Git 2.10 est disponible
    avec des améliorations relatives aux commandes Git push, Git clone et le renforcement de la sécurité des clés GPG

    Depuis quelques jours, la version finale de Git 2.10.0 est disponible. Dans cette nouvelle version du logiciel de gestion de versions décentralisé, il faut s’attendre à plusieurs améliorations.

    De prime abord, l’on note l’ajout de nouvelles fonctionnalités permettant au client Git d’éditer un rapport détaillé lors de l’envoi des données sur le serveur distant en exécutant la commande "Git push". Il faut rappeler que dans les versions antérieures, lorsque vous exécutez cette commande, il se trouve que la barre de progression affiche un ensemble d’éléments tels que les données envoyées, celles restant à envoyer, la vitesse de transfert, etc. Toutefois, lorsque l’opération est achevée, aucun rapport n’est fait quant à ce qui se passe au niveau du serveur distant. Pour résoudre ce problème, des améliorations ont été introduites dans cette nouvelle version afin de fournir aux utilisateurs de ce programme des rapports post-opération de réception.

    En plus de ce rapport détaillé introduit dans cette nouvelle version, nous avons également la fonctionnalité "keepalive" permettant d’envoyer des paquets de données sur le réseau afin de garder la connexion active même lorsque vous n’êtes pas près de votre terminal.

    Il faut souligner que ces deux nouvelles fonctionnalités présentées plus haut sont en œuvre côté serveur et sont rétrocompatibles avec toutes les anciennes versions de Git. Il est donc inutile de faire une mise à niveau pour ceux qui utilisent l’application cliente, mais le fournisseur d’hébergement lui a besoin de le faire pour que vous puissiez utiliser ces fonctionnalités.

    Du côté de la commande "Git clone" utilisée pour cloner les dépôts à distance, l’on a également des améliorations qui permettent d’avoir des indicateurs de progression précis lors de la vérification de la réception des données sur le serveur distant.

    Au niveau de la sécurité, Git 2.10.0 apporte une nouvelle option de configuration "log.showsignature" afin de vérifier les signatures pour chaque appel fait avec la commande "Git log".

    En outre, nous avons le format de sortie par défaut pour la vérification des signatures qui a changé et montre maintenant le id de clé GPG au format 64 bits, même avec les anciennes versions de GPG. Cela a été implémenté afin de résoudre le problème de fausses clés qu’il est possible de générer afin de les faire entrer en collision avec les id de clés dans un espace 32 bits.

    Autres nouveautés dans cette version, Git 2.10.0 accueille maintenant les attributs permettant de barrer des mots ou de mettre des éléments en italique. En dehors d’améliorations, plusieurs autres nouveautés sont également disponibles et concernent la gestion des archives, la génération des dates après l’année 2100, la gestion des protocoles, etc.

    Source : Notes de version de Git 2.10.0

    Et vous ?

    :fleche: Que pensez-vous des nouveautés de cette nouvelle version ?

    :fleche: Quelles sont les améliorations que vous souhaiteriez voir dans ce programme ?

    Voir aussi

    :fleche: Forum Git

    :fleche: Forum Logiciels libres open source

  3. #3
    Membre régulier Avatar de hucste
    Homme Profil pro
    IT en Arrêt Chronique de Sans-T !
    Inscrit en
    Juin 2016
    Messages
    78
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Lot et Garonne (Aquitaine)

    Informations professionnelles :
    Activité : IT en Arrêt Chronique de Sans-T !

    Informations forums :
    Inscription : Juin 2016
    Messages : 78
    Points : 113
    Points
    113
    Par défaut Long ID : pourquoi pas ... il aurait mieux vallu utiliser "fingerprint" !?
    Bonsoir,

    Que le projet Git améliore sa sécurité et surtout l'usage des clés GPG, en soit, c'est très bien.
    Là, où je suis surpris, c'est qu'il s'arrête à l'usage des "Long ID" alors qu'il est manifeste depuis 2013, qu'il faut privilégier l'usage de l'empreinte des clés GPG, car les identifiants GPG posent problèmes ... il existe même des guides de bonnes pratiques pour utiliser de manière correcte et sécurisée les clés GPG, et certains sont carrément des références à suivre au plus près.

    Après avoir "étudié" toutes ces informations correspondantes, j'avais écrit fin avril 2016 un article à ce propos nommé "Du bon usage sécurisé de GPG", transcrivant en français toutes ces recommandations disponibles bien avant en anglais.

    https://debian-administration.org/users/dkg/weblog/105 <= où pourquoi ne pas utiliser les informations GPG ID mais bel et bien l'empreinte (fingerprint) GPG.

    Quant aux bonnes pratiques, je laisse à chacun le soin ... de lire ... puis d'agir ! ;-)

    ----

    Je sais que je ne suis pas un grand technicien informatique, voire informaticien du tout ... et que je m'expose très certainement en publiant cette réponse ... mais je suis très surpris que l'équipe de Git est fait ce choix.
    Si les risques sont modérés, voire minimes, à utiliser les empreintes GPG, plutôt que les identifiants GPG, pourquoi ne pas faire ce choix ?!

Discussions similaires

  1. Réponses: 17
    Dernier message: 16/10/2010, 17h05
  2. Réponses: 0
    Dernier message: 18/09/2010, 19h56
  3. Réponses: 0
    Dernier message: 26/09/2009, 13h36
  4. Réponses: 0
    Dernier message: 26/09/2009, 13h36
  5. Réponses: 0
    Dernier message: 07/02/2009, 16h05

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