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

91–100 of 130 posts

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

#91

Post by lionkor »

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.

No, if your commits are meaningful and have plenty of context, like they should, then you are not looking for the author. Instead, you are looking for "why is this here", and the commit should tell you.

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

#92

Post by lionkor »

TZubiri wrote: post #66
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.

No. You are thinking of git bisect

No, bisect is not blame but for commits. Blame shows you which COMMIT is to blame. That's my point.

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

#93

Post by Lanolderen »

kazinator wrote: post #65
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.

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.

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

#94

Post by account42 »

I don't think the comparison to git blame is needed/warranted. While the 'blame' in git blame suggests the tool is about identifying authors its main purpose is to identify commits so that you can find out the context of why something was changed. Instead this tool seems to be a fancy `git shortlog -sn`.

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

#95

Post by account42 »

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?

You can't put an alias on your CV.

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

#96

Post by account42 »

TZubiri wrote: post #66
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.

No. You are thinking of git bisect

Bisect shows which commit is responsible for a yes/no behavior change. Blame shows which commit is responsible for a line of code. Both are useful for finding the responsible commit but for different things.

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

#97

Post by account42 »

igorbark wrote: post #60
mdaniel wrote: post #59

Earlier quoted context omitted.

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!

If malicious code ends up in your $PATH you have much bigger problems than git having a seamless plugin architecture.

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

#100

Post by anilakar »

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…

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.

Post reply on HN