DEV Community

Blaming Git Blame

Sandra Spanik on June 23, 2021

In this article I make a case for renaming the feature git blame to a neutral equivalent (e.g. git author or git inspect). I argue that the use of ...

Read full post

Colin McEwan • Jun 23 '21

Removing the blame command itself is a fairly small amount of work, the hard part is getting community buy-in and making the transition work. The largest issue is breaking the interface to existing scripting which uses blame.

While it's easy enough to restore that functionality for whoever needs it using git alias, doing so system-wide in many systems would still be a massive disruption.

However! There's precedent in git already for admonishments when using deprecated, or to-be-deprecated functionality (like relying on default pull behaviour). Perhaps a first step would be drafting language for and publishing a patch to provide a message when a user types git blame, to suggest the alternative annotate (or introduced alternate) and frame the user's experience better?

Sandra Spanik • Jun 23 '21 • Edited

If C was in my language repertoire, I'd be patching away!

"The user discussion and development of Git take place on the Git mailing list -- everyone is welcome to post bug reports, feature requests, comments and patches to git@vger.kernel.org (read Documentation/SubmittingPatches for instructions on patch submission)."

Do you think a feature request or bug report is a good place to start?

I was also thinking that Github could play a role in this. All that would be required on their part is making a tiny UI change, which would help spur momentum. They're certainly branding themselves as a super inclusive company, so in theory they might be amenable?

I know GitLab has done this before, then reverted back to blame. This link has details and a very interesting discussion: gitlab.com/gitlab-org/gitlab/-/iss...

teamradhq • Jun 24 '21

I think this is a really interesting discussion, and you make some points that I've not considered before. Although I feel that Linus' comments detract from this discussion. Firstly, because your quotes are almost a decade old, and Linus' efforts to self-moderate his bad language has been well publicised. Secondly because, as you explain later, the term predates git. And finally, as you point out, Linus isn't even responsible for implementing blame.

Personally, I've never felt any negative emotions about blame, although I often chuckle when I think to myself "Who the hell wrote this?" only to blame and see that I wrote it last year!

And when I read comments about how blame exists so we know which co-worker to blame, all that person is saying to me is that they don't understand its purpose:

Git blame is a git command which reveals what revision and author last modified each line of a file.

The key here is: revision and author. It's also important to understand that the author is not necessarily human. It could be a merge commit, or an automated build commit. It could also be that the author isn't just one person - maybe it's the pilot in a programming pair, or a colleague sat down and wrote that line. Perhaps the commit is a squashed commit containing someone else's work.

My point is that we're less interested in "blaming" the author than the revision.

As for renaming it, I feel that blame is adequate and accurate. Using author is insufficient because it doesn't accurately describe what it provides. Similarly, something like praise doesn't make sense to me. Mainly because we almost never look at the existing code of working implementations. And given the author might not be human it seems a bit strange to praise a machine.

To give an example, my most common use for blame is to identify when and where bugs were introduced:

Looking a file I suspect that unlucky line 13 might be the cause of a bug.

git blame file | grep 13\)
# 63ab903 (Paul 2021-06-17 11:44:05 +1000 13)   oopsie(daisy);

Then I checkout this revision to verify if the bug is present.

git checkout 63ab903

If the bug is present at this commit, I'll check previous revisions until I find one where the bug is absent.

git checkout HEAD~10
# 3d2e091

Then I'll checkout the branch and do a bisect.

git checkout branch-name
git bisect start 
git bisect good 3d2e091
git bisect bad 63ab903

And if bisect lands on the same commit, I now know where the bug was introduced.

# Bisecting: 0 revisions left to test after this (roughly 0 steps)
# [63ab903138aea32c3e32a90ec86ddfef6f3c2948] getIndex accepts negative value

Now I'll git blame file again, checking for that revision:

git blame file | grep 63ab903
# 63ab903 (Paul 2021-06-17 11:44:05 +1000  7) import { toDataSets } from './toDataSets';
# 63ab903 (Paul 2021-06-17 11:44:05 +1000 13)   oopsie(daisy)
# 63ab903 (Paul 2021-06-17 11:44:05 +1000 36)   const output = elements.reduce(toDataSets)

I'd also check for other files from this commit.

git --no-pager diff --name-only 3ca5d95a~1 
# file
# file1
# file2
# file3

And blame those as well...

At no point, am I blaming people, I'm blaming the code revision that's responsible for the error that's occurred.

For me, changing to something like praise would be weird. Once I've isolated a bug to a revision, why would I then praise its contents?

And for you, if you feel uncomfortable with blame define an alias in your .gitconfig to use whatever language you want:

[alias]
awesome = blame

Then you can git awesome file instead. It's the great thing about being computer literate, you can define your own language to interact with your machine (-; my personal favourite is git f*ckit that I regularly use to nuke any changes when I accept that my entire approach is wrong ;-)

Sandra Spanik • Jun 24 '21

Hey, thanks for your comment and for taking the time to write it. But, I have to ask: did you really read my article in full? I actually mention git alias as well as why it's not an adequate solution, pre-empting replies like yours, so I'm surprised to read your comment.

In your reply, you also dismiss the entire section about how language subconsciously affects individuals. Your argument seems to be that because you understand git blame better than others and as a result don't feel negatively affected by it, the naming of git blame is totally fine.

Just because you personally don't feel affected, doesn't mean other people won't.

We clearly have different sensitivities when it comes to language, because I'd never winky smiley anyone the way you just winky smiley'd me - to me, it feels rude. It's okay that you don't, and I'm not offended, but it's important for you to be aware that just because you think certain language is cool, doesn't necessarily make it so for everyone. Becoming an inclusive industry means being aware of these cross-cultural and individual differences and accommodating the norm so as to cause the least amount of harm possible.

I am also concerned about the cumulative effect on an entire industry rather than just the impact on any one individual.

Fair point about my mentioning Linus' past behaviour. I felt his past behaviour illustrated the general mindset that led to the naming of git blame in the first place quite well. I hopefully make it clear enough that it wasn't directly responsible for it, and specifically link to an article about him having changed. I take your feedback on board though.

teamradhq • Jun 26 '21 • Edited

You’re welcome, and I did read your article in full. Did you?

Given your post's topic, it seems ironic to call people rude or dicks... If you truly believe about stepping away from shame culture and towards openness and inclusivity, how about you start by not shaming people and instead moderating your own behaviour and language?

Git alias does solve a problem. The reason I mentioned it is because your pre-emptive supposition is wrong. If your problem is that you don’t want to write git blame defining an alias allows you to not type the word "blame".

Similarly, this snippet solves your problem, if your problem is that you don't want to see the word "blame" on GitHub:

document.querySelectorAll("a[href*='blame']")
  .forEach(el => {
    el.innerText = 'Author' ;
  });

If you really feel this language is a problem for many people, you could use this as a basis for a browser extension so that other people can utilise it. If many people use it, GitHub might even take notice and implement this as a feature. Nobody is stopping you from doing this and it would certainly be a more productive use of your time than insulting individuals.

And if seeing the word is an issue for you in vscode, you’re entirely welcome to checkout the extension you’re using for blame and modify it to substitute another word.

This is the great thing about being a programmer: you see a problem and you have the tools to fix it.

I don’t dismiss the subconscious effects language has on individuals. Obviously it could be harmful to call [redacted] and [redacted] dicks because they expressed a different opinion to yours. It doesn't seem very genuine to tell your audience to be mindful of the language they use as it may cause negative psychological responses in others, then say something ageist like that is soooo two thousand and late.*

Similarly, calling someone rude for signing off their post with a positive emote in a reply to a post that signs off with a positive emote is hypocritical and discriminatory. I mean seriously! You'd never use an emote in a discussion? Clearly you didn't get to the end of your article!

Passing judgement on someone who, unlike you, doesn’t have access to an emoji keyboard with star eyes isn’t very inclusive or accommodating, and I wonder if you’d have a problem with an emote in a post whose contents affirm your opinion, or if it's just because emoticons are sooooo two thousand and late and you hate old people.... if you still think using emotes in textual communication on the internet is inappropriate, you should remove them from your article (bearing in mind that emotes are language too).

[edit] and reading your replies to other comments, it’s clear you are discriminating as you didn’t call out other posters who signed off with a wink emote, and you seem to think it’s okay if you emote at people… obviously your rules don’t apply to you, just the people who are different to you.

Comments on individuals and insults to strangers (like yours) make our industry less inclusive. I hardly think that [redacted] or [redacted] would feel very welcome or safe to contribute to this discussion after being called old dicks... and you have no hope of changing an industry when you can't even follow your own guidelines!

Your statements thus far show a clear lack of empathy for people who are different from you and I hardly think you'd do well in a cross-cultural, diverse team with your current outlook and behaviour. My only hope at this point in our interaction is that you at least see the irony of your public shaming of individuals with different perspectives in an article telling an industry to avoid shaming individuals. I hope you take some time to contemplate what you need to change in yourself to be the change you want to see in an industry.

Sandra Spanik • Jun 26 '21 • Edited

I disagree with a lot here, and am hurt by your conclusions. You're making on the surface reasonable-sounding accusations that fall apart upon closer inspection, because your premises are false.

You continue to suggest my problem would be solved if I aliased git blame or programmatically removed the word blame from Github in my browser. This demonstrates I have either not been able to convey my point to you via the medium of my article, or that you're intentionally ignoring entire paragraphs.

I describe how the effect of git blame on any one individual is negligible but how it has an industry-wide cumulative effect. I never characterise this as my problem to begin with, which you disregard in all your replies.
I pre-empt replies like yours by mentioning why git alias is not an adequate solution - it doesn't address that blame remains the default wording for an entire industry.
As for your code snippet. I can only conclude you assume I don't know about DOM manipulation or about how to implement it. You're wrong on both accounts. Besides, it takes more work than your bit of code to make the change permanent. If you're going to flex your coding muscles at me, perhaps suggest something that actually works.
A browser extension also doesn't address the default. Neither does a new VS Code extension. Suggesting I build something from scratch, once again, ignores the premise of my article. I maintain that patching git itself is the most straightforward way to shift the default.
You do make a fair point about censoring names. I will. I stand by my decision to include the screenshots though, for the same reason I stand by my choice to include examples of Linus' past behaviour. They're both exemplary of an overall, industry-wide norm that has led to naming choices like git blame. Equally, I stand by my choice to infuse the article with light-hearted humour in order to make the 15-min read more palatable. Blaming any one individual for the harmful convention would have indeed been hypocritical, but asking individuals not to be dicks going forward and indicating that a cultural shift has happened over the last 2 decades is not. Besides, the effects of language are weighted by the power dynamics it exists within. I'm hardly causing harm here in the same way a feature that affects millions and shapes our default is, or in the same way a leader with livelihoods depending on them would be.
"star-eyed-emoji" ≠ "winky emoji" and there's no way you can frame my use of emojis as hypocritical. I didn't even call you out on the use of yours - I merely said that it's exemplary of our differences. The fact you're getting hung up over this and are trying to twist it into a portrayal of me as a hypocrite signals to me this is no longer a reasonable, factual discussion, but a personal attack.

And so I can only assume you're intentionally trying to hurt me. I will leave your comments up but I am putting up boundaries and disengaging from any future discussion. You've made this personal by intentionally misconstruing or ignoring my perspective on a multitude of issues and whilst I'm appreciative of factual debates, I draw the line at people attacking me.

૮༼⚆︿⚆༽つ • Jun 24 '21

Patching git doesn't solve the problems. You also need to patch Github, Gitlab, VSCode Gitlens extension, Jetbrains IDE, and billion of softwares that use git-blame feature and contain word "blame". This is blasphemy to blame and I blame you for suggesting this 😃

Sandra Spanik • Jun 24 '21

Yes. I believe strongly that they should ALL change. I know it’s a long article but did you read the whole thing? Because I mention Github and extensions too.

GitLab actually patched blame previously but then reverted back to it...

I’m not sure if you’re joking or not about the last part - but if you disagree, I’ll just leave it at that! I’ve made a strong case in the article itself so if that didn’t convince you, my commenting won’t either. 😅

૮༼⚆︿⚆༽つ • Jun 25 '21

I'm just joking 😀
Well, you can just rewrite git from scratch in other system-level language while doing optimization and making it more intuitive without blaming others 😉
github.com/Byron/gitoxide

Sandra Spanik • Jun 25 '21 • Edited

If you had read my article in full, then you’d know I am against blaming others and not actually drawing the conclusions you seem to think I am. I do, however, advocate for kindness, a thoughtful use of language, and moving away from the kind of humour you’re consistently showing in your replies.

૮༼⚆︿⚆༽つ • Jun 25 '21 • Edited

Sorry for not answering your question. Asking your audience whatever they fully read your article or not is kinda insulting. It's like that you are assuming they don't have a capacity to read the whole article. And I'm sorry if the joke didn't fit and seems rude to you, it's not my intention. I'm just one of many developer whose bad with words that you can found everyday.

About gitoxide, the experiment started in 2009 (12 years ago, 4 years after Git released) where the author try to implement git-core in Go. At the same year, the author also write a Python wrapper for git. After 2 years, the rewrite started again but now in C++ to exercise advanced features of C++0x and use both STL and Boost libraries. Now the author maintain both gitPython (a Python wrapper of git) and gitoxide (a full Rust rewrite of git). Hope this pique your interest contributing to gitoxide while enriching Rust ecosystem. In case you just started to learn about Rust, check out cheats.rs

Cheers.

Sandra Spanik • Jun 25 '21

Hey, I totally agree - I feel like such a dick each time I suggest that! I really try to avoid it. I'm sorry I didn't in this case. But the reason I suggested you haven't read my article in full is because you implied I'm blaming an individual for the feature. When in fact, I try really hard not to! 🙂

Gitoxide sounds like an amazing project. But I have neither the time nor the skills or inclination to contribute to it. Moreover, it doesn't fix the problem I describe.

The point I'm trying to make here is that the current default is harmful. And the default is git (as well as github, gitlab, git extensions in IDEs etc), not gitoxide.

Quick metaphor to make sure we're on the same page: suggesting I go off and write a different source control tool is like saying to someone who sees corruption in their government and wants to fix it to go off and create their own government elsewhere, instead of advocating for less corruption within their own country. Hope this makes sense.

In any case, thanks for the discussion!

fizzybuzzybeezy • Dec 7 '21

When I started learning Git (had previously used SVG and Mercurial a little bit) I was also surprised and a little chagrined to see the keyword blame. I was not bothered about it in terms where I hope no one blames me for anything. I screw up frequently (especially with code) and understand how to admit my mistakes and work to correct them (make amends/improve/ect.).

Although it didn't rise to the level of me refuse to use the tool, I was bothered more in that I didn't want to get in the mindset of blaming anyone for something as simple to do as coding errors. Otherwise, this stems from the context that I've studied anger management materials which spoke to the phenomenon of "victim anger" that can lead to feelings of distrust and at extremes, maybe even rage.

Breaking the habit of blaming is kind of at the cornerstone of that therapy.

Otherwise, thanks for writing this article! As mentioned, I've thought on this topic some and I found it funny and enlightening. I look forward to your next blog post!