`git who` – Quem escreveu este código?!

• git-who é uma ferramenta CLI para encontrar os responsáveis por componentes inteiros ou subsistemas de uma base de código
• Diferente do git blame, o git-who opera na unidade da árvore de arquivos para identificar os autores do código
• Oferece três subcomandos, e cada um deles fornece uma perspectiva diferente sobre a autoria em um repositório Git

  • table

    • Padrão, exibe uma tabela resumindo as contribuições de todos os autores que fizeram commits no repositório
    • É possível especificar um caminho para filtrar apenas commits de arquivos em um caminho específico
    • Também é possível especificar um nome de branch, nome de tag ou um "commit-ish" para filtrar apenas os commits alcançáveis a partir de um commit específico
    • É possível ordenar a tabela por diferentes métricas usando as flags -m, -c, -l, -f

  • tree

    • Exibe a árvore de arquivos, e cada nó mostra o autor que mais contribuiu naquele caminho
    • É possível anotar todos os arquivos usando a flag -a
    • Suporta as flags -l, -f, -m, -c

  • hist

    • Exibe um histograma/linha do tempo da atividade de commits para mostrar o histórico de contribuições no repositório
    • Suporta as flags -l e -f
• Opções adicionais para filtragem de commits
  • As opções --author e --nauthor permitem especificar autores para incluir ou excluir
  • As opções --since e --until permitem filtrar commits antes ou depois de datas específicas
• Cache: armazena dados em cache por repositório em XDG_CACHE_HOME. Para desativar o cache, defina GIT_WHO_DISABLE_CACHE=1
• Se o binário git-who estiver instalado no PATH, é possível executar git who sem configuração adicional. Se for instalado com outro nome ou se você quiser configurar explicitamente, é possível adicionar um alias nas configurações do Git
• Se existir um arquivo .mailmap no repositório Git, o git who o respeitará e contabilizará juntos os commits da mesma pessoa

• Métricas

  • Número de commits: indica quantos commits modificaram o caminho
  • Número de arquivos: indica a quantidade de arquivos únicos modificados pelo autor
  • Linhas adicionadas e linhas removidas: indicam quantas linhas foram adicionadas ou removidas no caminho

• Diferenças em relação ao git blame

  • O git blame identifica o commit que introduziu cada linha com base no código da árvore de trabalho, enquanto
  • o git who percorre parte do log de commits para agregar as contribuições
  • As duas ferramentas operam em níveis diferentes e fornecem informações diferentes

[GN⁺]

Comentários no Hacker News

• Em relação à análise de "quem escreveu o vim", dependendo do fluxo de trabalho pode parecer que colaboradores internos contribuíram mais

  • Se patches ou pull requests forem reformatados por colaboradores internos antes do merge, o mesmo trabalho pode ser contado duas vezes ou a contribuição pode ser atribuída apenas à pessoa que reformatou
  • O resultado não está necessariamente errado, mas é preciso cuidado ao tirar conclusões dele sem revisar o processo de contribuição

• Essa ferramenta é realmente muito legal. Testei rapidamente antes de encerrar o dia

  • Minha lista de desejos pessoal é a seguinte
    • Estatísticas baseadas em blame. É legal ver as contribuições de Bob e Alice, mas seria mais útil mostrar os verdadeiros donos de módulos/arquivos
    • Suporte a inclusão/exclusão por padrão. Por exemplo, eu não gostaria de ver estatísticas de arquivos json usados em testes ou de arquivos gerados automaticamente
    • Suporte a arquivo de configuração. Seria bom ter um arquivo baseado em TOML para salvar preferências no repositório Git
    • Empacotamento melhor. Por exemplo, o tarball Linux do v0.6 inclui "lixo" relacionado à Apple, e o gnu tar avisa sobre inconsistência no formato do arquivo

• Muita gente entende mal o git blame. Não é sobre quem fez, e sim sobre qual commit é o responsável

• É possível chamar git-who como git who. Basta configurar um alias nas configurações globais do Git

  • Funciona até sem alias. Por padrão, git whatever procura git-whatever no caminho e o executa

• Eu uso um apelido de versão simplificada, "nerdwars", para executar git shortlog -ns --no-merges. É uma boa forma de identificar os principais contribuidores de um projeto

• GitLab/GitHub deveriam adicionar um recurso que envia automaticamente um e-mail para o último autor das linhas de código modificadas quando uma merge request é enviada

• Essa ferramenta é excelente. Uso contabilidade com git-blame para acompanhar quanto código foi escrito por IA e por humanos em cada release do app

  • O "script de blame" está ficando lento conforme o repositório cresce. Tentei adicionar cache
  • Fico curioso se há planos para adicionar um recurso que limite as estatísticas com base em padrões de arquivos

• tig é um ótimo frontend TUI para Git e tem um belo subcomando tig blame

• O que falta no git não é quantas linhas ou commits um desenvolvedor escreveu. É mais algo como isto

  • Quem apagou esta linha
  • Quem é o dono deste método

• Algumas pessoas fazem commits usando dois e-mails diferentes. Por exemplo, um no computador de casa e outro no computador da empresa. Seria bom poder definir que ambos são a mesma pessoa