The Missing Git Command: The power of git blame without the blaming

The Worst Thing Ever

I know the worst code that I've ever professionally written. It was an overly generic UI component. It managed to combine a total misunderstanding of MVC, heavy constructors, an overly broad interface that leaked abstraction like a sieve, empty methods, liberal use of Object, and was driven by unexceptional-exceptions. Oh, and it couldn't be resized.

Not that any of that mattered. Despite all of the odds against it, it worked quite well from the user's perspective. Because of that last trait, my face-palm inducing code lives on. If you happen to have access to that codebase, you can git blame and you'll find my name pinned to each of the numerous mistakes.

In fact, through the power of Git, we can figure out who to blame for each and every line that causes us frustration. With just one command, we can bask in the warmth of knowing that we would have caught some obvious bug, elevating ourselves just a bit. And we do.

git blame is a really lousy command.

Well Actually…

As developers, we really enjoy being right. Like really enjoy it. Like at an unhealthy, borderline pathological level. The sheer volume of “Well Actually” cries to it. It's a pity really. I get it though. It's hard not to git blame.

“Do not judge others, and you will not be judged. For you will be treated as you treat others. The standard you use in judging is the standard by which you will be judged. – Matthew 7:1 NLT

It's problematic though. It pushes culture toward rightness as a necessity for survival. It pointlessly increases the penalty for failure. It allows us to mentally reclassify other developers as second-rate developers.

Okay, this sounds quite a bit hyperbolic. I mean, we could probably all agree that there's nothing inherently wrong with knowing who wrote a bit of hacky code. Looking to see who wrote a few lines is not likely to cause any real impending doom. Let's chalk this up to an exercise in pedantry, okay?

I don't think we can do that though, because I think there are a few other points that we'd also agree on.

• It's hard to learn from someone that you consider second-rate.
• It's hard to learn if you think someone considers you second-rate.
• It's hard not to let ego and opinions subtly show in conversation.
• It's hard not to let opinion be affected when we cherry-pick the worst code for examination.
• If we're honest, the biggest use case behind git blame is to watch a good train wreck.
• We can't enjoy someone's train wreck without taking a small measure of their dignity, even if they don't know it occurred.

The Starting Position

Regardless of anything I've posted, we need the functionality of git blame. Sometimes knowing the origin of a line is actually important. Sometimes git annotate just won't cut it. So, what do we do? Personally, I'm starting here:

git config --global alias.humanize blame

Pointless? Probably. Missing the big picture? Almost undoubtedly. Still, if I'm a bit slower to roast a fellow committer, then git humanize works.

It's hardly world changing, but it's a first step, which is good because we collectively have so far to go. git blame isn't even the worst offender for divisiveness. It just happens to be the one that I think we're more aware of when we do. We haven't even considered the impact of our vocabulary (e.g. “Really?", “Wait, you don't X?", “Certainly you use X, right?", practically all usages of the word “Obviously”, etc.)

Still, a start is a start. If we can start turning developers back into humans again, there might just be a chance for us to address some of the other issues later. Until then, let's resist the urge to blame. Let's start to humanize.