Journal Sortie de Git 2.9

Posté par  . Licence CC By‑SA.
Étiquettes :
21
16
juin
2016

Un rapide journal pour vous dire que le logiciel de gestion de version décentralisé le plus connu et le plus meilleur (on sera vendredi dans 20 minutes, c'est bon…) vient de sortir en version 2.9 !

Au menu :
* La possibilité d'exécuter une commande, après chaque commit, lors d'un rebase, grâce à l'option -x : git rebase -x 'make test'

  • Une amélioration [forte appréciable, NdA] du rendu des diff (cf. l'exemple donné dans l'article de makina-corpus.com)

  • La parallélisation de commandes git concernant les sous-modules s'étend : après git fetch , c'est maintenant git clone et git update qui peuvent être parallélisés.

  • La possibilité de faire de l'ASCII-art avec git describe !!! \o/
    (inutile donc indispensable)

L'annonce officielle est ici
Un article en français qui explique les principales nouveautés est là
La release-notes complète

  • # git rebase -x

    Posté par  . Évalué à 5. Dernière modification le 17 juin 2016 à 01:43.

    La possibilité d'exécuter une commande, après chaque commit, lors d'un rebase, grâce à l'option -x : git rebase -x 'make test'

    J'ai été assez surpris en voyant l'annonce[1], parce que ça laisse sous-entendre que l'option -x est une nouveauté, alors que ça n'est pas du tout le cas (sur ce PC par exemple j'ai la 1.9.1 et l'option est déjà présente).

    J'ai l'impression (mais je peux me planter, je n'ai pas creusé plus que ça) que la nouveauté c'est la possibilité d'utiliser l'option -x même sans être en mode interactif : git rebase -x 'make test' n'est pas une commande valide sous git 1.9.1, il faut faire git rebase -i -x 'make test' et ça ouvre l'éditeur de rebase interactif.

    [1] l'annonce officielle, pour sa part l'article en Français listé dans le journal donne bien la bonne explication.

  • # Annonce officielle

    Posté par  (site web personnel) . Évalué à 9.

    Le lien que tu donnes n'est pas vraiment l'annonce officielle. C'est un article sur le blog de GitHub (très bien écrit par ailleurs), et même s'il y a un lien évident entre Git et GitHub, ça reste important de ne pas confondre les deux. Un article sur Git sur le blog de GitHub n'est pas plus officiel que n'importe quel article sur Git sur n'importe quel blog.

    Sinon :

    La possibilité de faire de l'ASCII-art avec git describe

    Ça me parait être un raccourcis un peu étrange. git describe donne maintenant une description meilleure d'un commit, et git log ne casse plus l'ascii-art qui utilise des tabs (ce qui n'est pas du tout inutile, c'était une vraie demande de Linus qui en avait marre de voir les jolis messages de commits bien alignés utilisant des tabs cassés par le préfixe à 4 espace de git log), mais ce sont deux fonctionnalités différentes .

    • [^] # Re: Annonce officielle

      Posté par  (site web personnel) . Évalué à -3.

      Le site de git est hébergé par github, le dépôt officiel évidemment, et github est le contributeur majoritaire à git depuis des années. Le seul "intrus", et non des moindres certes, puisque c'est le mainteneur officiel (mais pas le plus gros commiteur ces dernières années) est chez Google. Les conférences git sont organisées par github.

      Que tu le veuilles ou non, si le code est bien sûr libre donc ne leur appartient pas, la "vie" de git c'est github (et google).

      • [^] # Re: Annonce officielle

        Posté par  (site web personnel) . Évalué à 4.

        Euh non il est maintenu a part avec une procédure proche de celle de Linux :
        https://github.com/git/git/blob/master/Documentation/SubmittingPatches

        Git Source Code Mirror - This is a publish-only repository and all pull requests are ignored. Please follow Documentation/SubmittingPatches procedure for any of your improvements. This is a publish-only repository and all pull requests are ignored. Please follow Documentation/SubmittingPatches procedure for any of your improvements.

        • [^] # Re: Annonce officielle

          Posté par  (site web personnel) . Évalué à -1.

          Le seul "intrus", et non des moindres certes, puisque c'est le mainteneur officiel (mais pas le plus gros commiteur ces dernières années) est chez Google.

          Euh non il est maintenu a part avec une procédure proche de celle de Linux :

          Ouais bah tu penseras à corriger tout l'internet, qui désigne Junio Hamano comme mainteneur (et au passage super l'argument "non y a pas de chef, c'est plutôt comme Linux", t'as entendu parler de Torvalds ?).

      • [^] # Re: Annonce officielle

        Posté par  (site web personnel) . Évalué à 10.

        Je connais bien la communauté Git, merci (cherches mon nom dans les logs si tu n'es pas convaincu).

        Le fait que GitHub soit un gros contributeur de Git est évident. Mais la communauté Git reste une communauté décentralisée, chacun y apporte ce qu'il veut. GitHub apporte beaucoup de code, l'hébergement de git-scm.com, et Junio Hamano y pousse son code régulièrement (mais le dépôt https://github.com/git/git/ n'a rien de plus officiel que git://git.kernel.org/pub/scm/git/git.git/). Si tu cherches une définition de « Git » en temps qu'entité légale, ce qui s'en approcherait le plus serait la Software Freedom Conservancy qui héberge le compte en banque.

        L'annonce la plus officielle des releases est faite par Junio Hamano, en publiant les releases notes relues et commentées par la communauté. Le blog de GitHub est un complément très appréciable, mais c'est une initiative unilatérale de GitHub, avec un texte sous leur contrôle et leur propriété.

        Ça a l'air d'un détail, mais ce genre de confusion entretient une confusion bien plus embêtante entre Git et GitHub, par exemple on a chaque année des candidats en Google Summer of Code qui candidatent dans l'organisation Git et disant qu'ils veulent contribuer à GitHub, ou des gens qui postent sur la mailing-list de Git en posant des questions spécifiques à GitHub.

    • [^] # Re: Annonce officielle

      Posté par  . Évalué à 1.

      Pour la confusion git describe / git log, la mise en page de l'article que j'ai écris n'aidait pas (tout dans le même bloc sans sous-titre…). Donc j'ai englobé les éléments du "Et sinon…" dans une liste, ça permet de mieux discerner les différents éléments ;)

  • # diff et hooks

    Posté par  (site web personnel, Mastodon) . Évalué à 7.

    Pour moi les deux principales nouveautés sont l'heuristique sur les diff (qui détecte bien un nouveau bloc de code) et la possibilités de surcharger le path par défaut des hooks d'un projet.

    Pour l'heuristique sur les diff, c'est bien mais je pense que ça ne réglera pas le problème dans les outils externes pour afficher un conflit et le résoudre (j'utilise meld ou vim). À moins bien sûr que cet algo soit intégré par la suite dans ces outils (et je ne vois pas pourquoi ce ne serait pas possible)

    Pour les hooks, ça permet (avec une seule option de conf) de définir où se trouve les hooks des projets. En entreprise, avec plein de projets, ça simplifie grandement les choses.

    Par exemple moi je me suis défini un petit hook pre-commit qui vérifie la présence d'espaces-insécables dans les fichiers SQL. En effet je suis en bépo et l'avantage de pouvoir faire facilement un espace insécable fait aussi que d'écrire en capitales en maintenant la majuscules ne manque pas de me faire taper de temps en temps un espace insécable que certaines base de données (Oracle par ex) ne considèrent pas comme un caractère d'espacement. Du coup ce petit script m'empêche de commiter un truc qui marche pas et m'indique où est « l'erreur ».

    Par contre, je suis obligé de copier ce fichier dans chaque projet (ou faire des liens symboliques, guère mieux). Avec la 2.9 ce sera mieux, et ça c'est cool ;-)

    • [^] # Re: diff et hooks

      Posté par  . Évalué à 2.

      Pourles diffs il faut que je fasse un comparatif avec l’heuristique «histogram» qui me donne plus satisfaction que l’heuristique par défaut. Sauf si quelqu’un a déjà fait un comparatif ici ?

    • [^] # Re: diff et hooks

      Posté par  . Évalué à 1.

      Par exemple moi je me suis défini un petit hook pre-commit qui vérifie la présence d'espaces-insécables dans les fichiers SQL.

      Personnellement, j'affiche dans vim les caractères invisibles (tab, espaces, insécable, trailling spaces, …). C'est excessivement pratique, et ça permet de s'assurer que l'on ne fait pas de typo lors de l'édition. Je pense que ces deux techniques se complètent très bien.

      bépo powered

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.