Stories with Tag blaming

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

  permalink

  Posted: 2025-03-18 20:20:09

  Verbose tl;dr

  git-who is a new command-line tool designed to improve Git blame functionality for large repositories and teams. It aims to provide a more informative and efficient way to determine code authorship, particularly in scenarios with frequent merges, rebases, and many contributors. Unlike standard git blame, git-who aggregates contributions by author across commits, offering summaries and statistics such as lines of code added/removed and commit frequency. This makes it easier to identify key contributors and understand the evolution of a codebase, especially in complex or rapidly changing projects.

  The Hacker News post introduces "Git who," a new command-line interface (CLI) tool designed to enhance the Git blame functionality, specifically targeting large-scale or "industrial-scale" Git repositories and complex projects. Traditional git blame can become slow and resource-intensive when used on files with extensive histories and frequent contributions. "Git who" aims to address these performance bottlenecks by optimizing the blame operation.

  The tool, written in Rust, leverages several strategies to achieve improved speed and efficiency. It parses the output of git log -p --follow -- <file> but implements its own internal logic for analyzing the changes and attributing them to specific authors, rather than relying on Git's built-in blame mechanism. This independent processing allows for more targeted and efficient computation of blame information. The tool's focus is strictly on identifying who last touched each line of a file, omitting the date and time information usually provided by git blame. This streamlined approach contributes to its performance advantages.

  The post emphasizes the tool's suitability for very large files and repositories where traditional blame operations might struggle. The core functionality boils down to displaying a concise, line-by-line attribution of authorship, presenting only the author's name or identifier for each line in the specified file. The output is designed to be easily parsed and utilized by other tools or scripts. The project is open-source and available on GitHub, encouraging community contributions and further development. The author positions "Git who" as a valuable addition to the toolkit of developers working with large and complex Git projects.

  • git
  • cli
  • command-line
  • Tool
  • blaming
  • blame
  • version control
  • Software Development
  • Open Source
  • GitHub
  • developer tools
  • productivity
  • Code
  • programming

  Summary of Comments ( 54 )
  https://news.ycombinator.com/item?id=43404548

  Verbose tl;dr

  HN users generally found git-who interesting and potentially useful. Several commenters appreciated its ability to handle complex blame scenarios across merges and rewrites, suggesting improvements like integrating with a GUI blame tool and adding options for ignoring certain commits or authors. Some debated the term "industrial-scale," feeling it was overused, while others pointed out existing tools with similar functionality, such as git fame and the "View Blame Prior to this Commit" feature in IntelliJ. There was also discussion around performance concerns for very large repositories and the desire for more robust filtering and sorting options. One user even offered a small code improvement to handle empty input gracefully.

  The Hacker News post about "Git who," a CLI tool for industrial-scale Git blaming, has generated several comments discussing its utility, potential alternatives, and specific features.

  Several commenters appreciated the tool's focus on speed and efficiency, especially when dealing with large repositories and blame history. One commenter highlighted the slow performance of git blame in such scenarios and expressed interest in trying git-who. Another user questioned the necessity of a new tool, suggesting that tools like git log -S might suffice. A response to this suggested that git-who offered more convenient filtering options and a clearer presentation of results, especially for identifying the introduction and removal of lines of code.

  The discussion also touched on the complexities of accurately attributing code changes in large, collaborative projects. One commenter pointed out the challenges posed by code refactoring and merging, which can make it difficult to pinpoint the true origin of specific lines. This commenter suggested incorporating features to handle code moves and rewrites effectively.

  A few commenters expressed interest in the tool's integration with other development tools and workflows. One suggested the possibility of integrating git-who with code review platforms or IDEs to provide more context during code analysis.

  The ability to quickly identify the author of specific lines of code, especially in large codebases, resonated with many commenters. This is particularly relevant in industrial settings where understanding the history and evolution of code is crucial for maintenance, debugging, and future development. The speed improvements offered by git-who over traditional git blame were seen as a significant advantage.

  Overall, the comments suggest a positive reception to git-who, with a focus on its potential for improving developer workflow and efficiency in large-scale Git projects. The discussion highlights the challenges of code attribution in complex projects and suggests avenues for further development and integration.