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

41–50 of 130 posts

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

#41

Post by ants_everywhere »

davely wrote: post #22
orthoxerox wrote: post #17

Earlier quoted context omitted.

Isn't that what git bisect is for?

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. 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…

I'm not quite sure what you're saying, but blame just tells you the last person and commit to change a line.

If you want to know which commit actually caused a problem you would use bisect. That may be what you're saying, but it sounded a bit like you are saying blame is better for tracking the culprit commit.

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

#42

Post by anotherpaulg »

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 table -include-file 
  git-who table -ignore-file
I tried to quickly add this functionality but unfortunately I don't know go.

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

#43

Post by eichin »

mckn1ght wrote: post #20
rav wrote: post #18

Earlier quoted context omitted.

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…

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.

I've been carrying around a copy of "git blameall" for years - looks like https://github.com/gnddev/git-blameall is the same one - that basically does this, but keeps it all interleaved in one output (which works pretty well for archeology, especially if you're looking at "work hardened" code.)

(Work hardening is a metalworking term where metal bent back and forth (or hammered) too much becomes brittle; an analogous effect shows up in code, where a piece of code that has been bugfixed a couple of times will probably be need more fixes; there was a published result a decade or so back about using this to focus QA efforts...)

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

#44

Post by weaksauce »

mckn1ght wrote: post #20
rav wrote: post #18

Earlier quoted context omitted.

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…

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.

there is https://github.com/emacsmirror/git-timemachine which is really nice if you use emacs.

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

#45

Post by weebst »

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…

That's a neat idea, I can see how it'd be useful.

If you have a shell that supports extended globbing, you could do something like:

  $ git who table */**/*.go
That works for me using Bash. I believe all that's happening here is that Bash is expanding the globs and passing a long list of individual filepaths as arguments to git who. Git who then passes them to git log so that it only tallies the commits you'd get by running:

  $ git log */**/*.go

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

#46

Post by qudat »

numbers wrote: post #9

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!

At pico.sh we have been experimenting with TUIs and remote clis successfully for a few years, you can see how we build our ssh tui app here: https://github.com/picosh/pico/tree/main/pkg/tui

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

#47

Post by chatmasta »

mmcclimon wrote: post #11

> 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.

Has this behavior been the source of exploits in the past? Something about it feels dangerously presumptuous to me.

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

#48

Post by remram »

wilg wrote: post #39
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.

Many people enjoy pretending that the term "blame" in "git blame" is not a funny little programmer joke that we don't have to be upset about.

It's funny because it always ends up telling me I did it.

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

#49

Post by dvt »

ants_everywhere wrote: post #40
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.

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 blamed before for changes which were technically my fault, but while my code was to spec, some unrelated part of the code I was interacting with was not (iirc it was some multi-threaded nonsense like a race condition or something).

It was a super-stressful week of constantly having to defend my design decisions and white-boarding my thought process (think of the "am I taking crazy pills?!?" scene in Zoolander) as my senior coworker tried to gaslight and throw me under the bus.

Maybe I've had a uniquely bad experience with it, but I've vowed to never use it (as a way to attribute `blame`). Code should be holistically understood and it's your job as a technical leader to know how the parts move, resolve issues without drama, and make sure your whole team is on the same page: this is a cohesive team, not an adversarial dick-measuring contest.

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

#50

Post by anotherpaulg »

weebst wrote: post #45
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…

That's a neat idea, I can see how it'd be useful. If you have a shell that supports extended globbing, you could do something like: $ git who table */**/*.go That works for me using Bash. I believe all that's happening here is that Bash is expanding the globs and passing a long list of individual filepaths as arguments to git who. Git who then passes them to git log so that it only tallies the commits you'd get by ru…

Yup. It’s a complex enough set of in/excludes that I think that would get unwieldy for my use case.

Details here:

https://github.com/Aider-AI/aider/blob/main/scripts/blame.py

Again, nice work on your tool. I’ll spend some more time trying to harness it for my need.

Post reply on HN