Hacker News Reader

Comment by khendron | Hacker News Reader

I've always thought 'git blame' was a badly named command. The word 'blame' has such negativity attached to it. The command should have been called 'git who'.

View on HN

You can always alias it to "git praise".

git config --global alias.praise blame

'git blame' is an excellent name, because who write a piece of code shouldn't matter. For a coder that's ready to take responsibility, figuring out who did what doesn't matter. All that matters what the code is now, whether it serves the purpose of the software and whether/how it should be changed.

I've never needed to use 'git blame' and I see no reason to, unless you really are just trying to look for a person to blame.

It's very useful to figure out who to ask about a particular piece of code. It's also occasionally useful to track down when it was changed (what commit) to give context for why things are the way they are.

If the person who always has trouble with boundary conditions wrote the code, then I can assume the missing boundary condition was accidental, not some subtle “feature” that I need to out-clever.

Also if the code is from a time frame before we agreed to stop writing code a certain way, that’s one thing. If it’s new, the person needs some feedback.

Seconded! I am the sole contributor (or the main one) on most of the git repos I am working on--they are research prototypes and I'm a PhD student so it's mostly solo work. So, I'm the only person to "blame" when looking at a piece of code, but it is a useful command that lets me find the commit and the context for why I implemented an algorithm in a certain way after a few months.

Another example: I use the nightly Rust compiler as a library, which have unstable API. git-blame helped track down which commits change the APIs I use when I'm updating the compiler version my project depends on. git-bisect is the other useful part of git for this purpose.

Reply on news.ycombinator.com