This is neat.
I made a similar powershell script recently but reverse search from filename to find the authors by commits.
Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
81–90 of 130 posts
Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#82I look forward to the inevitable upgraded version, “git whom”.
Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#83Earlier 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…
I acknowledge that I have no idea what happened in this situation. Please don't take this as me justifying mean behavior.
> Code should be holistically understood and it's your job as a technical leader to know how the parts move
That's true when we design something. Once the design is done, and is broken, we have to tear it back apart to understand WHAT is broken. That's when blame is useful.
I love using git blame. I love it even more when it comes back with something I made, because then I get to learn. When something I thought was safe turned out to break something, that's an invaluable chance to understand the system better.
That being said, I've totally used the blame output to end a series of excuses from a junior about how "his code was definitely right, but everything else was garbage" because I really do not care. If it worked before, but doesn't work now, that's a problem. Part of the modern process of "fail fast" is also to build up taste about which parts of a working system are spooky.
I find that some people take the "blameless" culture too far, and use it as an excuse not to reflect on outcomes. They just ruffle the code whenever there's a big, and don't think critically about why that bug appeared. What that tells us about the system we're making.
Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#84This looks like an almost pure Golang program, but still has a Ruby dependency. Is there a component/library that Ruby provides, that Go doesn't have? Or some other logic going on?
I’m pretty sure it’s just using Ruby for rake, which is a task runner. So Ruby is only needed for the build process.
Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#85Earlier quoted context omitted.
> 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…
I acknowledge that I have no idea what happened in this situation. Please don't take this as me justifying mean behavior. > Code should be holistically understood and it's your job as a technical leader to know how the parts move That's true when we design something. Once the design is done, and is broken, we have to tear it back apart to understand WHAT is broken. That's when blame is useful. I love using git blame.…
I work at a company with a mess of a monorepo but the git history is a gold mine. It's fascinating digging back into history and reading why certain decisions are made, or random pitfalls the author discovered, or context that was missing. It absolutely feels like a bit of a detective mystery trying to dig back and figure out if some line of code is a bug that was meant to do something else, or is functioning as intended and the requirements changed, or something else entirely.
Ofc as my org has gotten bigger, we've lost a lot of the discipline around writing good commit messages so now it's just a mess of large code-changes with 1-line "bugfix" explainations :(
Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#86I like this one the best:
https://github.com/jayphelps/git-blame-someone-else
Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#87Things I'm missing in git are not how many lines or commits given developer did, which might lead in a poorly managed organisation to strangely calculated KPIs, but rather:
- who deleted this line (which one?)
- who is owner of this method (some guy refactored it or reformatted, but who is the REAL owner, or what was the history of this method)Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#88Things I'm missing in git are not how many lines or commits given developer did, which might lead in a poorly managed organisation to strangely calculated KPIs, but rather: - who deleted this line (which one?) - who is owner of this method (some guy refactored it or reformatted, but who is the REAL owner, or what was the history of this method)
Yes, exactly.
That is what I use git for each and every day.
Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#89For 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.
Re: Show HN: "Git who" – A new CLI tool for industrial-scale Git blaming
#90Things I'm missing in git are not how many lines or commits given developer did, which might lead in a poorly managed organisation to strangely calculated KPIs, but rather: - who deleted this line (which one?) - who is owner of this method (some guy refactored it or reformatted, but who is the REAL owner, or what was the history of this method)
> - who is owner of this method (some guy refactored it or reformatted, but who is the REAL owner, or what was the history of this method)
It doesn't work perfectly, but with magit you can jump to the revision before the refactor/reformat, then do another blame from there. I chased a line of code through several layers of refactors that way before and while the original author was long gone it did help explain why things were initially done that way.
I heavily depend on git-blame to understand code. It's one reason why I generally dislike "cleanup" changes that just change formatting/naming for the sake of it.