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.
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.
Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
21–30 of 130 posts
Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#22By 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.
Isn't that what git bisect is for?
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. Plus, if you work in a monorepo with about 60 PRs a day, it's hard to know if it was your code or an associated library someone touched.
That's exactly when git bisect helps. It quickly narrows down which commit introduced the bug when you don't know where to start looking. Once bisect identifies the problematic commit, you can then use git blame (if needed) to see who made those specific changes.
Edit: Cleaned up what I was saying to hopefully avoid confusion.
Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#23Cool 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.
Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#24I've been using a git alias for quite some time
`lead = shortlog -s -n --all --no-merges`
Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#25By 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.
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.
Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#26Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#27> This requires that you have Go, Ruby, and the rake Ruby gem installed.
That doesn't cut it for me. git - once built - depends on C libraries and Perl. If you want to add something onto git (that is not specifically targeting Go, or Ruby etc.) - it should not IMNSHO depend on other things.
That doesn't mean you can't write your tool in some modern fashionable language, but eventually you need to bring it down to earth (or rather earth + Perl).
Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#28> 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.
Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#29Followed the link, and the README said: > This requires that you have Go, Ruby, and the rake Ruby gem installed. That doesn't cut it for me. git - once built - depends on C libraries and Perl. If you want to add something onto git (that is not specifically targeting Go, or Ruby etc.) - it should not IMNSHO depend on other things. That doesn't mean you can't write your tool in some modern fashionable language, but eve…