`git who` – Qui a écrit ce code ?!

• git-who est un outil CLI qui permet d’identifier les responsables d’un composant complet ou d’un sous-système dans une base de code
• Contrairement à git blame, git-who fonctionne à l’échelle de l’arborescence de fichiers pour identifier les auteurs du code
• Il propose trois sous-commandes, chacune offrant un angle différent sur la paternité dans un dépôt Git

  • table

    • Par défaut, affiche un tableau récapitulatif des contributions de tous les auteurs ayant effectué des commits dans le dépôt
    • Il est possible de spécifier un chemin afin de filtrer uniquement les commits concernant les fichiers de ce chemin
    • Il est possible d’indiquer un nom de branche, un nom de tag ou un « commit-ish » afin de filtrer uniquement les commits accessibles depuis un commit donné
    • Les drapeaux -m, -c, -l, -f permettent de trier le tableau selon différentes métriques

  • tree

    • Affiche l’arborescence des fichiers, chaque nœud indiquant l’auteur ayant le plus contribué à ce chemin
    • Le drapeau -a permet d’annoter tous les fichiers
    • Prend en charge les drapeaux -l, -f, -m, -c

  • hist

    • Affiche un histogramme / une frise chronologique de l’activité des commits pour montrer l’historique des contributions au dépôt
    • Prend en charge les drapeaux -l et -f
• Options supplémentaires pour filtrer les commits
  • Les options --author et --nauthor permettent de spécifier les auteurs à inclure ou à exclure
  • Les options --since et --until permettent de filtrer les commits avant ou après une date donnée
• Cache : met en cache les données par dépôt dans XDG_CACHE_HOME. Pour désactiver le cache, définissez GIT_WHO_DISABLE_CACHE=1
• Si le binaire git-who est installé dans le PATH, il est possible d’exécuter git who sans configuration supplémentaire. S’il est installé sous un autre nom ou si une configuration explicite est souhaitée, un alias peut être ajouté dans la configuration Git
• Si un fichier .mailmap est présent dans le dépôt Git, git who le respecte afin de regrouper les commits d’une même personne

• Métriques

  • Nombre de commits : indique le nombre de commits ayant modifié le chemin
  • Nombre de fichiers : indique le nombre de fichiers uniques modifiés par l’auteur
  • Lignes ajoutées et lignes supprimées : indiquent le nombre de lignes ajoutées ou supprimées sur le chemin

• Différences avec git blame

  • git blame identifie, à partir du code de l’arborescence de travail, le commit qui a introduit chaque ligne, tandis que
  • git who parcourt une partie du journal des commits pour agréger les contributions
  • Les deux outils opèrent à des niveaux différents et fournissent donc des informations différentes

[GN⁺]

Avis Hacker News

• À propos de l’analyse de « qui a écrit vim », selon le workflow, il peut sembler que les contributeurs internes aient davantage contribué

  • Si des patchs ou pull requests sont reformatés par des contributeurs internes avant la fusion, le même travail peut être compté deux fois ou la contribution peut être attribuée uniquement à la personne qui a reformaté
  • Les résultats ne sont pas faux, mais il faut rester prudent lorsqu’on en déduit du sens sans examiner le processus de contribution

• Cet outil est vraiment génial. Je l’ai essayé rapidement avant de finir la journée

  • Ma wishlist personnelle est la suivante
    • Des statistiques basées sur blame. Voir les contributions de Bob et Alice, c’est bien, mais montrer le véritable propriétaire d’un module/fichier serait plus utile
    • La prise en charge de l’inclusion/exclusion basée sur des motifs. Par exemple, je ne veux pas voir les statistiques des fichiers json utilisés pour les tests ou des fichiers générés automatiquement
    • La prise en charge d’un fichier de configuration. Ce serait bien d’avoir un fichier basé sur TOML permettant de stocker des préférences dans le dépôt Git
    • Un meilleur packaging. Par exemple, la tarball Linux de la v0.6 contient des « déchets » liés à Apple, et gnu tar signale un avertissement d’incohérence de format d’archive

• Beaucoup de gens comprennent mal git blame. Il ne s’agit pas de savoir qui l’a fait, mais de déterminer quel commit en est la cause

• On peut invoquer git-who avec git who. Il suffit de définir un alias dans la configuration Git globale

  • Ça fonctionne même sans alias. Par défaut, git whatever cherche git-whatever dans le chemin et l’exécute

• J’utilise une version low-tech avec l’alias « nerdwars » pour exécuter git shortlog -ns --no-merges. C’est une bonne façon d’identifier les principaux contributeurs d’un projet

• Gitlab/Github devraient ajouter une fonctionnalité qui envoie automatiquement un e-mail au dernier auteur des lignes de code modifiées lorsqu’une merge request est soumise

• Cet outil est excellent. J’utilise une comptabilité basée sur git-blame pour suivre la quantité de code écrite par l’IA et par les humains à chaque release de l’application

  • Le « script de blame » ralentit à mesure que la taille du dépôt augmente. J’ai essayé d’ajouter du caching
  • Je me demande s’il est prévu d’ajouter une fonctionnalité pour limiter les statistiques en fonction de motifs de fichiers

• tig est un excellent frontend TUI pour git, et il dispose d’une magnifique sous-commande tig blame

• Ce qui manque dans git, ce n’est pas le nombre de lignes écrites ni le nombre de commits par développeur. C’est plutôt ceci

  • Qui a supprimé cette ligne
  • Qui est propriétaire de cette méthode

• Certaines personnes commitent avec deux adresses e-mail différentes. Par exemple, elles utilisent une adresse sur leur ordinateur personnel et une autre sur leur ordinateur professionnel. Ce serait bien de pouvoir les définir comme identiques