8 ポイント 投稿者 GN⁺ 2025-03-20 | 1件のコメント | WhatsAppで共有
  • git-whoは、コードベース全体のコンポーネントやサブシステムの担当者を見つけるためのCLIツール
  • git blameとは異なり、git-whoファイルツリー単位で動作し、コードの作成者を特定する
  • 3つのサブコマンドを提供し、それぞれのサブコマンドはGitリポジトリの著作状況について異なる視点を提供
    • table

      • デフォルトで、リポジトリでコミットしたすべての作成者の貢献を要約した表を出力する
      • パスを指定して、特定のパスのファイルに対するコミットだけをフィルタリングできる
      • ブランチ名、タグ名、または"commit-ish"を指定して、特定のコミットから到達可能なコミットだけをフィルタリングできる
      • -m, -c, -l, -fフラグを使って、さまざまなメトリクスで表を並べ替えできる
    • tree

      • ファイルツリーを出力し、各ノードはそのパスで最も多く貢献した作成者を表示する
      • -aフラグを使って、すべてのファイルに注釈を付けられる
      • -l, -f, -m, -cフラグをサポートする
    • hist

      • コミット活動のヒストグラム/タイムラインを出力し、リポジトリへの貢献履歴を示す
      • -lおよび-fフラグをサポートする
  • コミットのフィルタリングのための追加オプション
    • --authorおよび--nauthorオプションを使って、含めるまたは除外する作成者を指定できる
    • --sinceおよび--untilオプションを使って、特定の日付より前または後のコミットをフィルタリングできる
  • キャッシュ: XDG_CACHE_HOMEにリポジトリごとにデータをキャッシュする。キャッシュを無効にするにはGIT_WHO_DISABLE_CACHE=1を設定
  • git-whoバイナリをパスにインストールすると、追加設定なしでgit whoを実行できる。別名でインストールする場合や明示的に設定する場合は、Git設定にAliasを追加できる
  • Gitリポジトリに.mailmapファイルが存在する場合、git whoはこれを尊重し、同一人物のコミットをまとめて集計する
  • メトリクス

    • コミット数: パスを変更したコミット数を示す
    • ファイル数: 作成者が変更した一意のファイル数を示す
    • 追加行数および削除行数: パスに追加または削除された行数を示す
  • git blameとの違い

    • git blameは作業ツリーのコードを基準に各行を導入したコミットを特定する一方で、
    • git whoはコミットログの一部を探索して貢献を集計する
    • 両ツールは異なるレベルで動作し、異なる情報を提供する

1件のコメント

 
GN⁺ 2025-03-20
Hacker Newsの意見
  • 「vimを誰が書いたのか」の分析に関しては、ワークフロー次第で内部コントリビューターの寄与がより大きく見えることがある

    • パッチやプルリクエストが内部コントリビューターによってマージ前に再フォーマットされると、同じ作業が二重に集計されたり、再フォーマットした人にだけ貢献が帰属したりする可能性がある
    • 結果が間違っているわけではないが、貢献プロセスを検討せずに結果から意味を導く際には注意が必要
  • このツールは本当にすばらしい。1日の終わりに少し触ってみた

    • 個人的なウィッシュリストは次のとおり
      • blameベースの統計。BobやAliceの貢献を見るのもよいが、モジュール/ファイルの実質的なオーナーを示してくれるほうが有用
      • パターンベースのinclude/exclude対応。たとえば、テストに使うjsonファイルや自動生成ファイルの統計は見たくない
      • 設定ファイル対応。Gitリポジトリに好みの設定を保存できるTOMLベースのファイルがあるとよい
      • よりよいパッケージング。たとえば、v0.6のLinux tarballにはApple関連の「ゴミ」が含まれていて、gnu tarがアーカイブ形式の不一致を警告する
  • git blameは多くの人に誤解されている。誰がやったかではなく、どのコミットが原因なのかを見るためのものだ

  • git-whogit whoとして呼び出せる。グローバルなGit設定でエイリアスを設定すればよい

    • エイリアスなしでも動作する。デフォルトではgit whateverはパス上のgit-whateverを探して実行する
  • 低機能版として「nerdwars」というエイリアスを使い、git shortlog -ns --no-mergesを実行している。これはプロジェクトの主要コントリビューターを把握するよい方法だ

  • GitLab/GitHubは、送信されたマージリクエストによって修正されたコード行の最後の作者に自動でメールを送る機能を追加すべきだ

  • このツールはすばらしい。各リリースでAIと人間が書いたコード量を追跡するために、git-blameの会計を使っている

    • 「blameスクリプト」はリポジトリが大きくなるにつれて遅くなっている。キャッシュを追加しようとしていた
    • ファイルパターンに基づいて統計を制限する機能を追加する予定があるのか気になる
  • tigはすばらしいTUIのGitフロントエンドで、美しいtig blameサブコマンドを備えている

  • Gitに欠けているのは、開発者が書いた行数やコミット数ではない。むしろ次のようなことだ

    • 誰がこの行を削除したのか
    • 誰がこのメソッドのオーナーなのか
  • 人によっては2つの異なるメールアドレスを使ってコミットする。たとえば、自宅のPCと会社のPCで別々のメールアドレスを使う。同一人物として定義できるとよい