Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming

Original Article ↗ Hacker News Discussion ↗

Tool purpose & usage

  • git-who is seen as a neat TUI for summarizing contribution stats (files, lines added/removed, commits) and answering “who works on this repo” at a glance.
  • It’s effectively described as a more polished git shortlog -sn / git summary with a table UI and caching, not a replacement for line-level git blame.
  • CLI questions: -n controls number of rows (-n 0 for all). Some users note that git who works without an explicit alias because Git auto-runs git-<subcommand> found in $PATH.

Identity, filtering & performance

  • Common issue: contributors using multiple emails. Several people point to .mailmap; git-who respects it, though some GUIs (e.g., PyCharm) don’t.
  • Requests for features:
    • Blame-based ownership stats (per tree-ish) instead of just commit history.
    • Include/exclude patterns or files (e.g., ignore generated or test JSON), possibly via a config file.
  • Workarounds: shell globs and Git pathspec excludes; Git’s native :! excludes mentioned.
  • Performance is praised, including on very large, old repos with thousands of committers, especially due to blame/log caching.

Relation to other tools

  • Many alternative or complementary tools are mentioned: tig (TUI), VS Code GitLens / built-in inline blame, git summary (git-extras), git shortlog, git blameall, git-timemachine, Cregit (token-based blame), git-contacts, and joke tools like “git blame someone else.”
  • Some are inspired to explore Go-based TUIs and share other TUI projects.

Blame semantics: commits vs people

  • Big subthread clarifies:
    • git blame maps lines → last modifying commit; git bisect finds the commit causing a behavior change.
    • Many argue the commit and its message (context, ticket links, related changes) matter more than the person.
    • Others emphasize using blame to find someone to talk to in large, fast-moving teams.
    • Co-authors, separate author/committer roles, refactors, and formatting all complicate “who wrote this.”

Workplace culture, metrics & caveats

  • Concerns that tools like this can become “stack-ranking” or KPI fodder; line/commit counts are considered poor contribution metrics.
  • Some report blame being misused for scapegoating; others describe it as invaluable for debugging, learning, and historical “code archeology.”
  • Workflow caveats: squash merges, internal reformatting, and imports from other VCS can heavily skew attribution, so results need contextual caveats.