Please don't take HN threads on flamewar tangents. That's what we're trying to avoid here.

https://news.ycombinator.com/newsguidelines.html

`blame` is one of Git’s most useful features for me, because if I’m confused about a piece of code I can instantly check to see when that code was added and why. Does it fix a bug; if so what’s the bug tracker ID and how was it resolved? Why did the programmer chose to do things this way instead of some other way that seems more obvious? How did this change fit into the rest of the codebase, and were any other files or functions changed to match?

(Of course, the utility of this depends on how well people write commit messages. There’s nothing more annoying than looking at a blame and seeing “update somefile.java.”)

If your organization is using blame to stir up conflict and point fingers, that sounds like a human problem rather than a technical problem, and a problem that you would still have even if `git blame` never existed.

Something tells me I wouldn't want to work in whatever team you work with.

git blame is extremely useful for knowing when something was added, and what the context was. It is not about "blaming" people for mistakes.

I mean, it just tells you the commit that last changed a line...

Nah, that award is for team time logging tools. Blame is normally used as a "who to ask" tool. Often the answer it gives you is "who last refactored this file" or "who originally moved this file from another location and lost the link to the prehistoric era when the interesting stuff happened"

My tool is designed to obtain insights from Git history and I've never understood how people can take such offense to git blame. I do agree calling it "blame" was probably not the best thing to do, but the fact is, it serves a purpose, which is, it's designed to help you understand how a piece of code came about.

For you to call this feature "passive aggressive" must have been borne out of some traumatizing experience and for that, you have my sympathy.

Another word for blame is 'responsibility'.

In a political organization, it's good to take responsibility for something, but bad to blame. A generous interpretation of that is that the person/group who made the decision should raise their own hand, and that it's a faux pas for others to point them out.

In a healthy one, you can recognize it's the same thing, and the important thing is how you respond to it (i.e., it's important to understand the responsible party so you can understand the reasons/motivations for the action, and accept them or address them).

git blame is mostly used to answer the question "when did this change and how?"

Being able to answer that question is key for maintainers.

I'm sorry if you had bad experiences with git blame usage. People can be assholes sometimes.

It's not meant to be a finger pointing tool but can be used for that.

That's Linus for you, I guess?

I dunno, I always found `git blame` really funny yet at the same time, I empathize with those who are a little taken aback by it (including... what's the company's name who makes IDEs who calls it "annotate"... ?).

I largely love it because most of the time when I `blame`, that's exactly what I want to do. I don't need software to give me a nicer verb so I can pretend that's not what I'm actually doing.

And most of the time, the author is exactly who I thought it was going to be (which can result in jovial convos) or, more commonly, ITS ME! Oh, the humility. I guess I can see it being a problem if you work on a toxic team (shit, sorry) and yes, I do understand desire for a sheen of positivity in the language of the software we use, but pretty much every of the time I go to call `git blame`, I mean `git BLAME`. While it certainly does happen, I rarely find myself thinking, "Who wrote this amazing code!?? I MUST KNOW!!!" and in those circumstances, it actually soothes my ego to "blame" them for it :D

edited for grammar/spelling