[LeoNatan25]

I hate such things. It creates a terrible work environment. Instead of focusing on the git blame and git punish, everyone should just focus on git commit fixes to make the code work. Does it really matter who put the bug? We are all humans, we all make mistakes.

[tmd83]

While the name maybe a bit unfortunate or maybe made just for fun, git blame has actual use. While it's useful to see the commit log and figure out how the bug came to be, it can also be useful to talk with the respective developer if available and get an even better perspective.

[LeoNatan25]

Indeed, but this is a different thing entirely. Getting a perspective to a problem and working together to fix it is one thing, going and pointing fingers, even in playful manner, is different. In the long run, it creates an unpleasant work environment.

In our office, I always take the blame jokingly to lighten the mood. It's a running gag, we have three people who are more senior than the others, and we always say "it's his fault, and if not, it's the other one and if not, then it's Leo's fault" (I am the most senior). When a problem arises, it doesn't matter who inserted the bug, but how to fix it the quickest.

[icelancer]

You can just also use git annotate if you want to avoid the negativity.

[tmd83]

Yup, wasn't defending this one :). Did the git annotate came after blame cause in the olden time I remember seeing the git blame example.

These days I mostly use IDEA's annotate feature and don't even know what's the command used in the backend.

[bazzargh]

They both came from the earlier `cvs annotate` command. annotate is the original name (from 1996). While it was common to talk about cvs annotate as 'blame', I think it first became the name of a command in subversion 0.32.0 (~2003, rcs blame was ~2004, cvs annotate grew the blame alias ~2008)

[bbatha]

Subversion has blame, praise, and annotate depending on your mood. [1] Though I think blame was first.

[1] http://svnbook.red-bean.com/en/1.6/svn.ref.svn.c.blame.html

[dennisnedry]

I agree. I once worked for a large software company that had a lead dev who relished calling people out and belittling them in front of the other devs. Long story short, turnover rate was quite high for that business unit.

[hamstergene]

This tool might have an actual use if all it did would be to create a page with the relevant piece of code and commit metadata, so that when asking authors about it they would just open a link and didn't have to clone/locate/open anything.

But shaped like this, with the name, the graphics, the "whyyyyy" and the overall implication that the commit author had screwed up, it's indeed hostile and counterproductive.

[elsjaako]

I'm not sure what this is, but git blame doesn't have to be a hostile thing. Maybe it isn't named the best way.

It lets you find the reason why and context in which certain code was added.

[mfontani]

~/.gitconfig

[alias] praise = blame

git praise ./path/to/file

[dkersten]

Hmm, not a bad idea: [alias] who = blame

git who file

:)

[lsaferite]

I use it more for the 'when' aspect than the 'who' aspect.

[LeoNatan25]

Haha great! I will remember this.

[fs111]

old svn user?

[icelancer]

svn ships as annotate/praise by default. git annotate also works though praise does not unless you alias it as shown in this thread.

[greggman]

100% agreed. Along with a review sent to the person that wrote the bug. Ideally with a non accusatory note like "I think this code had an issue and I think this fixes it. Yea?". That way they can double check you understood the issue and they can learn from their mistakes. When I get a CL like that I usually write a "Doh! Sorry about that. Thank you for the fix".