Git Should Rename the Blame Command. It's Bad for Business. - Triplebyte Blog

Joseph Pacheco is a software engineer who has conducted over 1,400 technical interviews for everything from backend, to mobile, to low-level systems, and beyond. He’s seen every quirk, hiccup, and one-of-a-kind strength you can think of and wants to share what he’s learned to help engineers grow.

This is a companion discussion topic for the original entry at

Isn’t this why git annotate exists?


I don’t disagree with the points about “blame” being negative nor do I have a problem with aliasing it. Maybe it makes sense to point out how easy it is to alias?

Is it?

I record my shell history; I don’t merge history between machines but on the machine I’ve used the most I’ve called git ~20k times in the last several years. I’ve called push, status, commit, diff, add, checkout, log, pull over 1k times each (some a lot more). After that, clone, remote, rebase, branch, config, reset, merge all over 100 times.

I’ve called blame 47 times in that time. I’ve typoed git status more times than I’ve run git blame. So I guess I strongly disagree with the characterization that blame is one of the more popular commands.

I think attributing “seeing” the word “blame” to cause negative thoughts is maybe true and I don’t have a problem replacing it, but it’s difficult to have a positive culture by accident and if you are doing the right things existence of git blame shouldn’t affect your team whatsoever.

Generally I use blame when I do to find a commit that maybe helps explain why code is why it is, rather than finding someone to throw under the bus. However I find praise is probably the wrong word because when I’m calling it, it’s not because things are going well :slight_smile:


For those who lack this type of sense of humor and sufficiently thick skin, there is git annotate :slight_smile:

Many times I looked at a piece of code, wondered who that idiot was that wrote that line, ran git blame, and discovered that it was me :slight_smile:

In seriousness, we all make mistakes. Sometimes we right bad code. Sometimes we see what we think is somebody’s elses bad code and have strong emotions. If we learn to manage them properly - not suppressing, but at the same time, learning to express them in a way so that the giver and receiver both understand that we hate bad code, but we still love the developers who wrote it. This is how we grow.

To me git blame is not a negative statement. If somebody “git blames” me for some bad code I wrote and does it in a friendly joking manner as I am sure was intended by Linus and the team, I take it as a positive and laugh with them at my folly. Or I might disagree, and we can have a discussion, which will hopefully result in producing something much better than neither one of us envisioned originally.


Articles like this are the reason that git allows you to define custom aliases. Instead of writing ~1,400 words about this, the author could have just done this instead:

  1. Open ~/.gitconfig in a text editor
  2. Under the [alias] section, add a line credit = amend
  3. Done! Now you can run git credit and it will work exactly like git blame.

Well, it’s not why annotate exists, since I believe the annotate command was written before blame was introduced. But either way, blame certainly seems to be used more today, terrorizing young engineers left and right one command at a time. :nerd_face:

But thanks for the comment! We added a couple of lines to talk git-annotate.

And the day we no longer have to use an alias is the day we celebrate! But, agreed. This is good information for those who didn’t know it was possible. And a welcome practice to apply an alias if you can to shield your team (and especially young mentors) from the horror of blame.

Do you actually use git-credit?

It sounds as though the bigger problem in your trauma might have been a poorly run organization. Did they humiliate you in ways other than merely publishing a “git blame” listing for this bug? It’s fine to feel bad about a bug, but if your bug had a significant negative impact on a user community, doesn’t your testing organization share some of that responsibility?

The name “blame” was chosen for a good reason. It in effect says “this is a necessary and useful command, but it is possible that some jerks will try to use it to humiliate people, so beware” – I’m sorry that you didn’t get that from the jump, and even sorrier that there was no one around it to explain that to you.

An aside: contrary to what one responder has claimed, Linus Torvalds did not invent “blame”. The older source code management system svn has basically the same blame command. And even though Linus has famously called svn “the stupidest program ever written”, he did share a sense of humor with its developers about the development process.

I’m glad that your experience was not so traumatic that you couldn’t recover from it, but you do young people a disservice by clinging to your bitter memories of it and dreaming of a world of safe spaces governed by the psychobabble of the sort purveyed by the Brene Browns, Peter Sheahans, Christine Poraths, Andrew Newbergs, and Mark Reobert Waldmans of the world.

Don’t make snowflakes out of them.


Well said @David_Nadler. Completely agree.

It’s an interesting thought, though questionable whether a narrow interpretation of a word should impact millions of people who don’t share the same belief in its meaning. It’s likely blame will persist for longer than this article even if annotate or a similarly neutral term takes its place.

A key to well-run, non-toxic, and transparent organizations is the ability to define who is responsible for an action. git blame is agnostic in how it views identifying who is responsible in both positive and negative cases. There’s certainly no shame from the command itself.

My opinion is to find the work culture where you feel comfortable and resist giving words power you’d prefer they didn’t have.


Cannot agree more! Some words just do not have bad connotations in the techie community. Yes they may sound so to the suits, but who cares about the suits? : )

Processor interrupt? Sounds negative. Let’s rename it “request for attention.” This sounds positive. On the same note, halt? Oh boy, what a monster invented that! Let’s rename HLT to RNCD (Rest and Cool Down). Abort? Did someone invent that to subliminally bring politics into programming??? Programs should not abort or crash, they should be “precautionary stopped.”

I’m a linguist, among other things (I’m a SWE and a speech scientist, too), and I am staying as far as I can from the prescriptivism. Our language took hold in the hacker culture of the 60s, it’s nearly 60 years old. Attempting to forcibly PCize a language which have been live for two generations is both futile and will be met with entirely understandable resistance. Language is a living thing, and resists such a rough treatment.

Diplomats talk in a professional code that non-diplomats do not understand—why words that seem soft and neutral if not friendly actually mean the harshest hair trigger warning possible? Marketing people talk in a slang I’m not even trying to grok. And we the SWE also have own abstand language. “In which version of Emacs was this function added?”—“I do not remember, I think it was 23, but go blame it.” Nobody blames anyone here. And we also recognize our fellow guildsmen by it; societal identity is also tied to the language in a very important way!

A common element in techie’s¹ speech is its directness, and this is not only remarkable from the descriptive vantage point, but also has its direct effect on the end result. If engineers were talking to each other about mistakes, inconsistencies or flaws in roundabout hints instead of straightforward truth, the things that they build would more likely blow up on liftoff, or break down and flood a city, or crash down into a river with 200 cars and buses on it, or abort and freeze a bank or, in our epidemic time, unemployment payment service, or mess up scientific data collection. The more direct we are to each other (and we understand that ‘git blame’ is no more about blame than git(1) is a git), the better working contraptions we build (and this is the utmost reward for us!), and in the better world we end up.

¹ Thirty years ago I would say “hacker”, but the word has shifted its connotation, or perhaps even changed its semantic. It changed by itself: nobody wrote a blog post to change it, there was no movement for it, no proposals, no consensus (although, of course, some discontent among the graybeards that any language change causes). Language is a living thing, and it’s very easy to overestimate how much power we have over it: in fact, very little to none.


A boring bikeshed. This article caused me to unsubscribe from (what were typically quite interesting) Triplebyte update emails.


The name is perfectly okay. I don’t have any problems with it.


Funny that no one has yet pointed out that Linus joke “I’m an egotistical bastard, and I name all my projects after myself. First ‘Linux’, now ‘git’.” ( ).

In a culture where we encode into compilers and runtime exceptions brief, yet harsh words to encourage a tendency towards all exceptions just being handled cases, this fear of shame itself is at odds with our purpose. Shifting the shaming to an automated tool ensures that it is ever present, but should be paired with mentoring and providing a support network but also an incident response which leaves no one alone in handling the case when git blame finds you at 02:00 .

“Collective code ownership” ( ) is a goal, but in my experience is not reached, respected, nor encouraged in actual practice. Given that, I tend to prefer “owning” as much as possible w/ as little as possible being found via git blame. Optimizing against that is a challenge, but allows me to focus on the goal of this article, reaching out to support those who are on the other side of that ratio and helping them change their outcome to a more positive experience.

I especially <3 from the responses the git blame finding me as that idiot because it truly encapsulates the fact that we are all “impostors” doing our best to advance the field.

1 Like

Hah. I guess I can see how this might seem like a boring topic to some. But surely you can’t consider all UX stuff as bike shed issues, right? I once sat in a meetings where the debate to label a button “Chat” vs “Message” was quite lengthy. It wasn’t the most exciting stuff to talk about, but the impacts of those changes to user activity were pretty big. Are debates around changing the labels to git commands all that different?

I wonder if one would better learn from and appreciate this post if one were to search and replace “pixiedust” for “blame” before reading it.

1 Like

Best possible answer!

It is interesting that almost nobody agreed with the suggestion and folks took it mostly as an opportunity to talk about author’s trauma.
I do think these (author’s experience with git blame, and git blame itself ) are two separate issues. Probably if it was even named prod_contributor instead of blame, the author would have a bad experience with the command anyway, perhaps because of the humiliating context for him. So this is not git blame's fault per se.
However I see his point which we could use positive words wherever possible in life and I appreciate author’s initiative to address the issue. We don’t have to change it overnight or insist this command has to change now, but it is good to start thinking about the issue and not entirely dismissing it.
Thank you @Joseph_Pacheco for bringing this issue to my conscious!

1 Like

This essentially boils down to an XY problem: “My senior engineer at work made me feel embarrassed for introducing a bug - how do I rename git blame?”

Clearly, the name of a command is not the issue here. It’s company culture.