[HN Gopher] Show HN: "Git who" - A new CLI tool for industrial-s...
       ___________________________________________________________________
        
       Show HN: "Git who" - A new CLI tool for industrial-scale Git
       blaming
        
       I've always wanted a better way to explore the authorship data
       embedded in a Git commit log. I'm having fun building a CLI tool to
       do this.  It's a bit like the "Contributors" tab on Github that
       shows you how many commits each contributor has made but much
       faster and with many more options.  If you get a chance to try it
       out, please let me know. I'd love to hear feedback and suggestions.
       Thank you!
        
       Author : weebst
       Score  : 56 points
       Date   : 2025-03-18 20:20 UTC (2 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | andrewfromx wrote:
       | I like it. A problem I had right away is some people commit using
       | two different emails. Like one from home computer and one from
       | work computer. Would be nice to be able to define them as the
       | same thing.
        
         | jtwaleson wrote:
         | That's what the mailmap is for.
        
         | sebastianlay wrote:
         | You might be able to do that with built-in git functionality
         | called gitmailmap. It is basically a file where you can map
         | multiple names and emails to the same one.
        
           | Cadwhisker wrote:
           | It's great when you read further down the comments and come
           | across a gem like this. I had no idea this was possible;
           | thanks.
        
         | dolmen wrote:
         | git help mailmap
        
       | jtwaleson wrote:
       | Very cool, I'm working on something similar as part of a bigger
       | project (not TUI related). I'm interested in how you did blame
       | caching, will take a look at the implementation. I am trying to
       | do a "forward blame" so that the blame of new commits can be
       | created very quickly. Happy to exchange some thoughts around
       | this!
        
       | nextts wrote:
       | Don't tell the higher ups about this stack ranking tool.
        
       | natemwilson wrote:
       | Cool, but how do I increase the number of rows? Is it always just
       | the top ten?
        
       | ttyyzz wrote:
       | "This requires that you have Go, Ruby, and the rake Ruby gem
       | installed." - sticking to the binaries then :) Cool little
       | project, will try it tomorrow!
        
       | numbers wrote:
       | I love TUI tools but I'm not too familiar with Golang, now I am
       | thinking I should start looking into using go for TUIs
       | 
       | this is a great tool!
        
       | lionkor wrote:
       | By the way, git blaming is really misunderstood by a lot of
       | people; its NOT about who did it, its about which commit is to
       | blame -- that's different.
        
         | markerz wrote:
         | Ideally, you find the context for why a change was made
        
         | gleenn wrote:
         | Isn't this sort of an inconsequential point? The commit still
         | has one and only one author and that's almost certainly what
         | I'm looking for so I know who to go ask questions about their
         | code. I also use it to find the commit but less frequently.
        
           | lubutu wrote:
           | I mean, no. If you work on a codebase that's been going for
           | more than a few years, the author likely doesn't even work
           | there anymore. The commit is the important thing.
        
           | rav wrote:
           | On a small team I usually already know who wrote the code I'm
           | reading, but it's nice to see if a block of code is all from
           | the same point in time, or if some of the lines are the
           | result of later bugfixing. It's also useful to find the
           | associated pull request for a block of code, to see what
           | issues were considered in code review, to know whether
           | something that seems odd was discussed or glossed over when
           | the code was merged in the first place.
        
             | mckn1ght wrote:
             | I find the GitHub blame view indispensable for this kind of
             | code archeology, as they also give you an easy way to
             | traverse the history of lines of code. In blame, you can go
             | back to the previous revision that changed the line and see
             | the blame for that, and on and on.
             | 
             | I really want to find or build a tool that can
             | automatically traverse history this way, like git-evolve-
             | log.
        
         | orthoxerox wrote:
         | Isn't that what git bisect is for?
        
           | davely wrote:
           | Sometimes you don't know which commit actually caused the
           | problem.
           | 
           | e.g., you realize that something broke A/B test logic on
           | Friday. Sure, there are Jira tickets, but that's slow and
           | annoying to dig through. There are commit messages, but
           | things get squashed, etc. Oh, you also work in a monorepo,
           | which has about 60 PRs a day. Was it my code or an associated
           | library someone touched.
           | 
           | git bisect helps to quickly narrow it down -- i.e., we don't
           | know who / what commit to blame in the first place.
        
         | kemitchell wrote:
         | I have seen `git blame` used to blame specific people. I've
         | seen it work. Some of those people deserved some blame.
         | 
         | The manpage explains what the command does. How and why it's
         | used is up to the user.
        
           | lelandfe wrote:
           | Alternatively git praise https://github.com/ansman/git-praise
        
       | mmcclimon wrote:
       | > You can invoke git-who as git who by setting up an alias in
       | your global Git config
       | 
       | This works even without the alias, by the way: by default `git
       | whatever` will search your path for `git-whatever` and execute
       | it.
        
       | rednafi wrote:
       | Cool stuff. I like using Git via the CLI, but when it comes to
       | blame, I simply use the preview UI of the VSCode GitLens
       | extension. It takes half a second to launch it from the command
       | palette and inspect the blame.
        
         | davely wrote:
         | I have some VS Code extension (errr... not sure which) that
         | faintly inclines the git blame result on each line of code
         | you're working on. I find it kind of handy.
        
       | fmeyer wrote:
       | Nice one, works better than mine;
       | 
       | I've been using a git alias for quite some time
       | 
       | `lead = shortlog -s -n --all --no-merges`
        
       | syhol wrote:
       | I've been using `git summary` from tj/git-extras for a while. It
       | seems to do a similar job.
        
       ___________________________________________________________________
       (page generated 2025-03-18 23:00 UTC)