3 ms·

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

antris 5y ago
'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.
- kadoban 5y ago
  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.
  - hinkley 5y ago
    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.
  - maemre 5y ago
    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.
hnzix 5y ago
You can always alias it to "git praise". git config --global alias.praise blame

antris 5y ago

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

kadoban 5y ago
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.
- hinkley 5y ago
  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.
- maemre 5y ago
  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.

hnzix 5y ago

You can always alias it to "git praise". git config --global alias.praise blame