Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

101–110 of 130 posts

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

#101

Post by reubenmorais »

anotherpaulg wrote: post #42

This is great. I do this sort of git-blame accounting to track how much code is written by AI versus humans in each release of my app. My "blame script" has been slowing down as the repo size increases. I was just about to add caching, like you have. Have you thought about adding the ability to limit the stats based on a set of file patterns? Perhaps like this, where the file follows gitignore conventions? git-who ta…

Git natively supports excludes in all pathspecs, e.g. `git log -- ':!generated/'` to exclude files in the `generated/` folder from showing up in the log.

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

#102

Post by pjc50 »

gleenn wrote: post #14
lionkor wrote: post #10

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.

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.

At my last workplace, the codebase was about 25 years old, there were three of us, and one of us was the original author. You could simply guess "Gerald wrote this" and you'd be right nine times out of ten. However, it turns out that software developers have finite memory themselves, and svn blame was useful in tracing a line of code back to the original ticket.

Linking a line of code back to the commit is useful even if you can't ask the author about it. It tells you what other lines of code are involved and what the overall purpose is. It's significantly more useful if you can link it into documentation outside the code: ticketing systems, requirements docs, etc.

The main limit to svn blame in that situation was that quite often it would hit commit 1, when the codebase had been imported from Visual SourceSafe.

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

#103

Post by pjc50 »

dvt wrote: post #49
ants_everywhere wrote: post #40

Earlier quoted context omitted.

I'm pretty sure it's about who wrote the code. 'git blame' is named after the subversion and CVS blame features that do the same thing. Subversion docs are clear that it's a snarky name and that 'svn praise' and 'svn annotate' are neutral synonyms. Perhaps someone familiar with CVS can comment on its history there since it seems to be the first source control to add it. EDIT: and one of the main reasons it's a useful…

> EDIT: and one of the main reasons it's a useful feature is it tells you who to talk to to understand a piece of code, or to coordinate a roll back, or to do any other sort of communication. It probably matters more in a big company where code is changing frequently and you're unlikely to know everyone and what they're working on. It's actually a pretty awful feature because it misses so much context. I've been blam…

This is why blameless post-mortems and a healthy culture are important. I'm sorry you encountered such a hostile culture. Perhaps "git blame" has the wrong name, but the idea of traceability is still important.

Aviation is the shining example of this, combining high traceability (you should be able to track each part back to the factory and to all the technicians who have worked on it) with accident inquiries that are focused around finding cause and avoiding future risks rather than assigning blame.

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

#104

Post by patrickdevivo »

This is such a cool tool. It's a better approach to solving many of the questions I built MergeStat to answer (https://github.com/mergestat/mergestat-lite). It's been some time, but I also wrote a `git blame ...` parser in Go: https://github.com/mergestat/gitutils/blob/main/blame/blame.... :)

Amazing work and excited to dig into this more thoroughly

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

#105

Post by dspillett »

One thing to note, maybe particularly with reference to the “who wrote vim” analysis⁰, is that depending on workflow this can attribute more to internal contributors than you might assume by the results.

If a patch or pull request is sent but an internal contributor (the only internal contributor in Vim's case for a long time) reformatted it before merging then the same work is double-counted (if full history is kept) or only attributed to the reformatter (if history is squashed during/before merge).

This doesn't make the result wrong, of course, the tool is doing exactly what it says on the tin. But it does mean that, without reviewing the contribution process (current and past), you might need to be less definite¹, when stating a meaning derived from the result, because how the result is interpreted might not be quite right given the input data available.

----

[0] https://sinclairtarget.com/blog/2025/03/who-will-maintain-vi... in case you skipped by the link when looking at git-who's readme.

[1] perhaps just by giving caveats to make sure that the reader has sufficient context regarding the limit of the process

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

#106

Post by dspillett »

Lanolderen wrote: post #93
kazinator wrote: post #65

Earlier quoted context omitted.

git bisect is about which commit is to blame for a reproducible problem. git blame is about which author most recently touched each line (in what commit); i.e. is to "blame" for that line having its current content. You're right in that git blame is most useful for finding which commit touched a line. What was done in the commit is more important than who did it. git blame is very useful even in a solo project where…

Unless you get lazy like me and start committing only out of shame once the modified file count reaches close to triple digits or prior to doing very sketchy changes.

True, and I'm guilty three too, but there is a limited amount we can expect toolmakers to do to protect those of us who misuse their tools :)

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

#107

Post by dspillett »

what wrote: post #71
lelandfe wrote: post #25

Earlier quoted context omitted.

Alternatively git praise https://github.com/ansman/git-praise

Why wouldn’t you just set an alias in your global git config for this?

Perhaps the author intended further additions, perhaps transforming the output to apply filters or add spurious superlatives for humour value (“Great work on line 420, User6942!”).

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

#108

Post by m000 »

seanhunter wrote: post #89

For a low-tech version of this, I have long had an alias (which I call "nerdwars") to "git shortlog -ns --no-merges" which just gives the number of commits by contributor from most to least. It's a good way to get a sense for who the major contributors in a project are.

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. Number of blame lines per contributor would be overall much more accurate, and immune to different styles of committing (e.g. squashed mega-commits vs rebased self-contained commits).

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

#109

Post by Izkata »

gwbas1c wrote: post #74
lionkor wrote: post #10

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.

BTW, 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, ect, ect. "git blame" and similar tools often always show my name, even though I didn't write the code.

git log/blame have -C and -M to follow modified lines across files. Unlike other version control, you don't have to have used a special command to rename files, because it doesn't track files that way in the first place. The maximum -C can even look for sources in other commits.

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

#110

Post by justusthane »

anilakar wrote: post #100
Minor49er wrote: post #52

Earlier quoted context omitted.

> Subversion docs are clear that it's a snarky name and that 'svn praise' and 'svn annotate' are neutral synonyms. A few years ago, some Atlassian developer changed "Blame" in the BitBucket UI to "Annotate". I remember a lot of people being frustrated because they couldn't find "blame" anywhere and the change was never officially announced. It just happened one day Someone opened a ticket with BitBucket about it whic…

If I ever saw an "annotate" command I'd immediately assume it's for adding notes as metadata outside the actual software versioning tool, not for seeing who wrote the code in question. Nomenclature matters. Do not reinvent terms just for fun.

Agreed - I don't understand at all how the word "annotate" is being used here. It seems like "substitute" would be a better standin - as in "To whom can I attribute this code?"
Post reply on HN