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

51–60 of 130 posts

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

#51

Post by weebst »

anotherpaulg wrote: post #50
weebst wrote: post #45

Earlier quoted context omitted.

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.

Thank you very much!

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

#52

Post by Minor49er »

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…

> 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 which ended up drawing a lot of attention from frustrated users who couldn't find "blame", and their searches for it on Google led people to the ticket. Atlassian eventually responded saying that they made the change because "blame" sounds bad and can hurt people's feelings somehow (with no examples given of course, though ironically the dev who made the change certainly had hurt feelings after the upset masses had some choice words for the short-sighted decision. Though Atlassian doubled down and I believe closed the ticket without reverting the change, so the confusion remains, as far as I know)

I don't think that they ever mentioned the Subversion/CVS parallel that was drawn to choose that name, so it was really confusing why that was selected. But this comment shed some light on that ancient incident

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

#53

Post by cdogl »

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…

That sounds like an awful workplace culture. I doubt the name of the git command is responsible, though.

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

#55

Post by m000 »

Lovely tool. Thanks for the release! I had some fun with it before calling it a day.

Here is my personal wishlist after a short test-drive.

- Blame-based stats. While it is nice to see an overview of the historical contributions of Bob and Alice, this is not something that I would use on a daily basis. What would be more useful, is to present the same tables based on the blame lines of a tree-ish. This would show the de-facto "owner(s)" of modules/files, something which comes handy when asking for help with something or even assigning reviews. One could also run this iteratively over the history and get some nice timeline graph.

- Support for pattern-based inclusions/exclusions. E.g. I am not interested to see stats on the json files used by tests. Or any kind of auto-generated files (e.g. django migrations).

- Support for a configuration file, to store your preferred settings in your git repo. Something TOML-based perhaps.

- Better packaging (nit). E.g. the linux tarball for v0.6 contains some apple-related "junk" and gnu tar complains about archive format incompatibilities.

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

#57

Post by awesome_dude »

Minor49er wrote: post #52
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…

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

> ironically the dev who made the change certainly had hurt feelings after the upset masses had some choice words for the short-sighted decision.

Dev probably became the public face for a decision made by someone else (eg. Product owner, TL, whatever the business structure is in Atlassian)

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

#59

Post by mdaniel »

chatmasta wrote: post #47
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.

I am guessing it only resorts to that expansion if it dosesn't _already_ know about the command, because $(printf '#!/bin/sh\necho pwned\n' > /bin/git-status; chmod 755 /bin/git-status; git status) results in the thing happening that you'd expect, not a mysterious message

FWIW, both brew and kubectl also have adopted this behavior (of $(basename)-plugin style verb extensions) so I find it unlikely they'd all do it if it was a straight-up facepalm

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

#60

Post by igorbark »

mdaniel wrote: post #59
chatmasta wrote: post #47

Earlier quoted context omitted.

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

I am guessing it only resorts to that expansion if it dosesn't _already_ know about the command, because $(printf '#!/bin/sh\necho pwned\n' > /bin/git-status; chmod 755 /bin/git-status; git status) results in the thing happening that you'd expect, not a mysterious message FWIW, both brew and kubectl also have adopted this behavior (of $(basename)-plugin style verb extensions) so I find it unlikely they'd all do it if…

probably adding a confirmation message the first time the alias is used for each command would be good, it would be nice to know when i'm invoking git and when i'm invoking a third party binary regardless of any exploit attempts!
Post reply on HN