In the world of software development, understanding who wrote what code is crucial for collaboration, debugging, and knowledge sharing. While Git's built-in blame command has long been the go-to tool for this purpose, a new open-source command-line utility called git-who is gaining attention for offering deeper insights into code ownership and contribution patterns.
Understanding Git Blame vs. Git Who
Git blame has been widely misunderstood by many developers. As one commenter points out, Git blaming is really misunderstood by a lot of people; it's NOT about who did it, it's about which commit is to blame -- that's different. While git blame shows which commit last modified each line of code, git-who takes a different approach by analyzing contribution patterns across entire files and directories, providing a more holistic view of code ownership.
The fundamental difference is that git blame focuses on line-by-line attribution, while git-who helps answer broader questions about who has contributed most significantly to specific parts of a codebase over time. This distinction becomes particularly important in large codebases with numerous contributors where understanding the big picture of ownership can be challenging.
The Problem with Traditional Git Blame
Traditional git blame has limitations that git-who attempts to address. For instance, when developers perform large refactorings, code reformatting, or file moves, git blame will attribute all those lines to the person who made those changes, even if they didn't write the original code.
One of the more frustrating things about 'git blame' comes about when cleaning up an old codebase: In my current job I had to move a lot of files, combine repos, reformat code, etc. 'git blame' and similar tools often always show my name, even though I didn't write the code.
This problem is particularly acute in large organizations where understanding true code ownership is essential for knowledge sharing and maintenance. Git-who provides different views into contribution patterns that can help overcome these limitations.
Features and Capabilities
Git-who offers several subcommands that provide different perspectives on code ownership. The log subcommand summarizes file and commit structures more insightfully than standard git tools. The user subcommand helps examine contributions to specific paths in the file tree, while the tag subcommand identifies authors based on the number of files edited.
One particularly useful feature is the ability to visualize contribution timelines with the bug subcommand, which generates a database of tasks sorting timelines of project contributions. This can be invaluable for understanding how a project has evolved over time and who has been responsible for different components during different periods.
The tool also supports filtering by author, time frame, and other parameters, making it flexible for various use cases. Additionally, it caches data on a per-repository basis, improving performance for repeated queries.
 |
|---|
| A screenshot of a GitHub repository illustrating the code structure and contributor history relevant to git-who's capabilities |
Community Reception and Suggestions
The developer community has responded positively to git-who, with many users appreciating its speed and insights. One user reported that for a Rails codebase approximately 18 years old with 1,695 committers and more than 220,000 commits, git-who completed its analysis in under 3 seconds.
Users have also suggested potential improvements, such as adding blame-based statistics to show the de-facto owners of modules or files, support for pattern-based inclusions/exclusions (similar to .gitignore functionality), and configuration files to store preferred settings.
Some developers have noted that git-who complements existing tools like git shortlog -sn, which provides a simple count of commits by contributor. However, as one commenter pointed out, Number of commits is not a very good metric to measure contributions. It would only work when there is an agreed style of commits and everyone sticks to that.
Integration with Existing Workflows
Git-who can be easily integrated into existing Git workflows. The tool can be installed via package managers like Homebrew or compiled from source. Users can set up Git aliases to make it even easier to use, allowing commands like git who or git wlog instead of the full git-who syntax.
For those working in containerized environments, git-who can be run as a Docker container without needing to install it directly on the host machine. This flexibility makes it accessible to developers in various environments and with different workflow preferences.
As development teams continue to seek better ways to understand code ownership and contribution patterns, tools like git-who represent an evolution in how we think about and analyze code authorship. By providing deeper insights beyond simple line-by-line blame, git-who helps teams better understand their codebases and collaborate more effectively.
Reference: git-who