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 git blame primes workplaces and teams for blame culture and contributes to unhelpful feelings of shame. The language we use shapes our cognition, feelings and behaviours in small but systematic ways, and it is for this reason that I argue renaming the otherwise useful feature git blame is long overdue. I also investigate the source code of git in an attempt to understand how the feature got introduced, and connect with its author to find that he, too, wishes the feature was named differently.
What is git?
Git is an open source version control tool with widespread adoption that allows individuals to track changes to files over time and revert back to previous versions of files at any time. It is extremely useful for collaboration and has become the de-facto standard for software engineering teams. While there are alternative version control systems, many companies consider a basic command of git a pre-requisite for employment.
What is git blame? 😳
Git blame is a git command which reveals what revision and author last modified each line of a file.
When I was first shown the feature, I chuckled nervously at the discovery. Being new to tech, I generously allow for the possibility that my code might not yet be, objectively, what one would call "the shit". Naturally, I immediately imagined my colleagues repeatedly invoking my name using git blame, subconsciously adding the tiniest bit of additional frustration to an ever-growing stinking pile of frustrations upon each discovery of me as the culprit. In 21st century language, I'd summarise my feelings about learning of git blameas follows: 👀.
Whilst my instinctual reaction was that of pre-emptive shame creeping in, it was quickly countered by some good old rational thinking. I feel safe in my workplace, knowing that my colleagues aren't on the hunt to assign blame for mistakes, and that my organisation values collaboration over rockstar developing.
I was told that the main utility of the feature is not enabling team members to blame each other for their poor code contributions, but enabling individuals to find out who would be the best person to ask about a specific part of a codebase. The ability to quickly identify the author of a given part of the codebase for follow-up questions is handy, and saves time.
If you're asking yourself, why would the feature be named
blameinstead ofauthor, when it primarily gets used to identify the code's author, then you and I are asking ourselves the same question.
Git blame is harmful 🤕
Let's assume we agree that git blame shouldn't get used with the intent of assigning blame within teams. A big assumption to make, that I bet some teams with archaic or authoritarian work philosophies would disagree with. But philosophical differences regarding effective collaboration are beyond the scope of this article.
Okay, so we're assuming we all agree - let's not blame each other and instead primarily use git blame to find the code's author in a blame-free context. Great. But even so, 2 issues remain:
- Why should the onus be on us developers to do mental gymnastics and internally rebrand
git blameasgit author, when in fact, the feature itself could just be namedgit authorin the first place? - Even though we can agree to see beyond its literal meaning, the naming of the feature still continues to affect us in systematic ways.
This is because language subconsciously shapes the way we think, feel and behave. Repeated exposure to the word blame in a work context is harmful. It feels implausible that in today's climate, where we rightfully pay attention to our language more than ever, a feature like git blame should be allowed to peacefully continue existing and priming workplaces for blame culture.
Language measurably shapes our cognition 🧠
The language we use demonstrably influences how and what we think. For example, existing cross-cultural differences in how we perceive time, distance and size can be traced back to how different languages construct these abstract ideas. Also, speakers of languages which use grammatical genders such as Russian or German are heavily influenced by the arbitrary grammatical gender of nouns. These speakers' visual representations of such nouns and their instinctive associations depend heavily on the noun's otherwise random gender. Even visual perception is not immune to the effect of language. For example, Russian speakers are better at distinguishing between shades of blue than English speakers because they have more words to describe them. You can read more about all of this here.
Language has a priming effect 🗣️
Priming is a phenomenon whereby exposure to one stimulus influences a response to a subsequent stimulus, without conscious guidance or intention. For example, exposing someone to the word "yellow" will evoke a faster response to the word "banana" than it will to an unrelated word like "sofa". Priming takes place outside of our conscious awareness, but it plays an important role in our daily lives. From influencing how we interpret information to our behaviour, priming can play a part in our perceptions, emotions, and actions. Marketers, advertisers and even social media engineers have sought to exploit this effect.
It's reasonable to assume that seeing the word blame repeatedly primes us for negative affective responses. If you are committing new code, thinking of the word "blame" is likely to introduce just the slightest bit of fear, shame or guilt. On the flip side, if you are the one investigating changes and see your colleague's name next to the word "blame", you will be more likely to actually assign blame to them and associate their name with a negative affective state.
Now let me pre-empt some questions a reader might have at this stage.
If it bothers you so much, why don't you just alias it? ❄️
I'm aware that git has a neat alias feature that allows you to replace any command with another. Technically, nothing's stopping me from renaming git blame to git candyfloss. But the feature is ubiquitous and difficult to avoid, so creating an alias in my local device would barely reduce my exposure to it.
image of VSCode blame extension
There are useful git extensions that display git blame, and even Github itself has a UI version of git blame that shows you the author and the name of the commit associated with each part of the codebase. According to the 2020 Stackoverflow Annual Developer Survey, more than 82% of us use Github, so the word blame really is near impossible to escape.
image of Github's blame interface (yes, this is what Github looks like in light mode)
If it bothers you so much, why don't you just use git annotate? ❄️
git annotate is another git command with nearly the same functionality. Whilst git annotate doesn't differ from the criticised feature by much, it doesn't solve the issue for the exact same reasons described above.
Having justified why git blame is worth discussing, let's now delve into its history.
What's to blame for git blame? 🔎
Git was created in 2005 by none other than Linus Torvald, the creator of Linux, who was at the time working on his operating system with a dispersed team of volunteer developers. Working remotely before it was cool, he was using the proprietary version control software BitKeeper, which was made available to his team for free. Until, one controversy later involving an engineer being accused of reverse-engineering the software, BitKeeper's founder Larry McVoy withdrew the agreement.
Torvalds soon announced he would go on a week-long holiday, and in true vacation spirit, created the first version of the version control tool that 82% of today's nearly 27 million developers use, probably all whilst reclining on a beach chair and sipping on a cold one.
actual footage of Torvalds implementing git (probably)
Git's success was a surprise to him. It's safe to say that carefully naming projects sensitively, especially those he never expected to take off in such spectacular fashion, wasn't Torvalds' priority nor inclination.
“The in-joke was that I name all my projects after myself, and this one was named ‘Git’. Git is British slang for ‘stupid person’,” Torvalds tells us.
That's right. Git is actually a British swear word. If you've previously noticed this and chuckled at the fact that git is eponymous with the swear word popularised by The Beatles and Ronald Weasley, the joke's on you - git's creator knew this full well. The README of Git elaborates even further:
"Git", the "stupid content tracker", can mean anything, depending on your mood
- Random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
- Stupid. Contemptible and despicable. Simple. Take your pick from the dictionary of slang.
- "Global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
- "Goddamn idiotic truckload of sh*t": when it breaks.
Open source
Git's maintenance continued to be led by one of the most active early contributors Junio Hamano, who is said to remain somewhat of a benevolent dictator to the git community up to this day. It's important to note that git is by no means one man's toy. It is the result of a decade and a half of collaboration and hard work by an active and caring community.
Their Code of Conduct speaks of a community that is respectful and kind. But the extent to which this is true is unclear to me because I am neither a contributor myself nor am I impervious to stories about the patriarch himself, Linus, occasionally telling contributors they should probably be retroactively aborted. A man who enjoys to jokingly call out stupid people who write stupid patches for being so stupid that it's a surprise they've managed to find a tit to suck on as stupid babies, is not a man I associate with creating welcoming communities.
Torvalds letting us all know what he really thinks of our code contributions (probably)
Whilst I must admit that I personally enjoy his particular brand of dark humour, I'd advocate for being more mindful of the power dynamics we are all part of, because whether we like it or not, our words can have unintended harmful consequences.
A theory started forming in my head: perhaps git blame was the result of the same strain of dark humour? Maybe a seemingly innocent but really quite insensitive joke that feels so on brand for the Linux creator's past? I say past here, because the man is apparently evolved now.
I'd like to think that, having known the many millions of developers who'd come into contact with the concept of blame on a daily basis as a result of a mildly amusing joke, the naming of git blame would have been reconsidered. I'd say, it's about time we retroactively abort it.
Getting to the bottom of git blame 🕵🏼♀️
Spoiler alert: as you might have already guessed, astute reader, my naive assumption that git blame started as a joke is, in fact, completely wrong. But let's dig into how I derived at this sobering conclusion.
Thankfully, git is so spectacularly useful that I didn't have to stop at simply theorising about my burning question of how, when and why git blame was introduced. The beauty of git itself being an open source project made with git, means that anyone can check out who authored which changes when.
In search of some answers, I put on my detective hat, raised a monocle to my eye, and downloaded Git's source code repo. To search for the earliest introduction of the string "blame" into the codebase, I used git log --all -p --reverse --source -S 'blame' .
The first mention of "blame" I found was in the documentation intended for users migrating from CVS, a competing version control tool. The changed file, in classic Linus fashion, begins with the following sentence: "OK, so you're a CVS user. That's ok, it's a treatable condition, and the first step to recovery is admitting you have a problem". Had programming not worked out for the man, standup comedy would have been a solid second choice.
Here's the bit that features the word "blame".
Author: Linus Torvalds torvalds@linux-foundation.org
Date: Wed Jun 8 13:19:31 2005 -0700
So, something has gone wrong, and you don't know whom to blame, and
you're an ex-CVS user and used to do "cvs annotate" to see who caused
the breakage. You're looking for the "git annotate", and it's just
claiming not to find such a script. You're annoyed.
Yes, that's right. Core git doesn't do "annotate", although it's
technically possible, and there are at least two specialized scripts out
there that can be used to get equivalent information...
The text suggests ex-CVS users were predicted to expect the command git annotate to produce what we now know as the git blame output, based on CVS itself supporting an annotate command. Neither of the commands existed in git at the time (although now, they both do).
At this point, it seemed to me like the jury was still out on whether the naming of git blame was the result of a joke or an intentional, serious, naming decision. But from reading through the documentation, it started seeming more and more like git blame was the result of a work ideology that starkly departs from mine, and embraces a culture where assigning blame is the norm and tolerance for mistakes is scant.
Still hungry for answers, I dug deeper and uncovered git's public mailing list archives.
The real origin of git blame 💫
In May 2005, a member of the git open source community sent an email, wondering how to replicate the CVS annotate feature. Linus replied saying that whilst he knows how to do it (obviously 💅), he's hoping someone else will, because he generally doesn't care about the feature enough. So much for my Torvalds-joke hypothesis.
Junio Hamano came forward and implemented a slow yet working algorithm in Perl, which became the base of future git blame implementations. Then, 2 people independently created their own versions - one of which became git annotate, named consistently with SVN, and the other became git blame .
Here's the "guilty" commit.
Author: Fredrik Kuivinen frekui@gmail.com
Date: Tue Feb 21 00:40:54 2006 +0100
Add git-blame, a tool for assigning blame.
I have also been working on a blame program. The algorithm is pretty
much the one described by Junio in his blame.perl. My variant doesn't
handle renames, but it shouldn't be too hard to add that. The output
is minimal, just the line number followed by the commit SHA1...
So here we go, git blame turns out to be described by its creator as a tool for assigning blame and was originally unequivocally intended to do exactly what it says on the tin - assign blame.
Admittedly, the finding is no sensation - my detective work has led me to the outcome most would have rightfully assumed to be true by default, without feeling the need to go off and do hours of research on the topic in the hope of discovering that, surely, this was all down to a simple misunderstanding or innocent joke gone awry.
However, Fredrik was not the first one to have implemented a "blame" algorithm. As he says in his commit message, he was working off of Junio's blame.perl, which makes copious use of the words blame and guilt itself, as shown below, in an excerpt from the blame algorithm's description.
How does this work, and what do we do about merges?
The algorithm considers that the first parent is our main line of development and treats it somewhat special than other parents. So we pass on the blame to the first parent if a line has not changed from it. For lines that have changed from the first parent, we must have either inherited that change from some other parent, or it could have been merge conflict resolution edit we did on our own.
The following picture illustrates how we pass on and assign blames.
In the sample, the original O was forked into A and B and then merged into M. Line 1, 2, and 4 did not change. Line 3 and 5 are changed in A, and Line 5 and 6 are changed in B. M made its own decision to resolve merge conflicts at Line 5 to something different from A and B:
+
+ A: 1 2 T 4 T 6
+ / \
+O: 1 2 3 4 5 6 M: 1 2 T 4 M S
+ \ /
+ B: 1 2 3 4 S S
+
In the following picture, each line is annotated with a blame letter.
A lowercase blame (e.g. "a" for "1") means that commit or its ancestor is the guilty party but we do not know which particular ancestor is responsible for the change yet. An uppercase blame means that we know that commit is the guilty party
Even I, self-appointed Language Police Officer™, can see nothing wrong with the above description. In the world of algorithms, removed from humans, the words "guilt" and "blame" are simply the most succinct descriptions of the variables' functionality. In this context, the drawbacks of their negative connotations don't outweigh their utility.
But the rabbit hole goes even deeper than Junio's blame.perl. Turns out, another competing source control tool called Subversion had already implemented a blame feature all the way back in 2003!
The usage of the term blame is likely the result of 2 things: the word's variable naming utility and the collective mindset at the time.
Contacting The Author 🗯️
When I contacted the git feature's author, Fredrik Kuivinen, he told me that he mainly called it blame because it had been called blame elsewhere already. He also added the following:
"In hindsight, I should have taken the opportunity to come up with a better name, e.g., "praise" which has been suggested by others."
I felt vindicated. My temporary career change to detective had been worth it - after all, the author himself appears to agree a naming change would be beneficial!
But at the time Fredrik was implementing the feature, coming up with a better name would have required an implausible amount of foresight on his part. Firstly, he would have had to anticipate the success of git and the future ubiquitousness of the feature. Secondly, he would have had to anticipate a cultural shift in tech.
Moreover, the same command already existed elsewhere, and going with the default produces less friction than changing the status quo. And judging by mail exchanges, other contributors also preferred the naming of "blame" over "annotate".
Therefore, we will be assigning NO blame to Fredrik for implementing the feature in this article.
What have we learned? 🎓
- The term
blamein a version-control context existed elsewhere prior to git, because it is a succinct descriptor, and a reflection of the collective prevalent mindset at the time that no single individual is responsible for. - Using words with negative affect in internal variables might in some cases well be the most elegant naming solution. But to, in 2021, name external commands in the same way, demonstrates either a lack of empathy for the end user or a lack of awareness of the significant impact language has on us all.
- Open source is magnificent. More work than I could have previously imagined went into git. I'm grateful for the hard work that continues to set the foundations of all technology that surrounds us.
This doesn't seem like such a big deal, why get hung up on it? 💁🏼
I agree that on an individual level, the existence of git blame feels easy to brush off. Once the initial twinge of surprise at discovering the feature subsides, it's easy to go back to work and never question it again. But as I've explained above, the language we are exposed to continues to affect us in subtle but real ways.
So whilst the effect of git blame on any one person might be negligible, its cumulative effect on an entire industry that encounters the feature every single day is significant. Over time, tiny amounts of shame and hesitation encountered by millions add up to a mountain of innovations foregone.
Moreover, many clearly still find it amusing that git blame exists. To those who do, I'd say: get with the times, folks. Being a dick is 2000 and late.
And although I have no science to back this up, I have the suspicion that some are more affected by the feature than others. Those who engage in more introspection, those who feel they have more to lose if they commit the wrong code, those who experience a wider range of emotions overall. As we move towards creating a diverse workforce open to individuals from any background, we would do well to also adjust our language to be more inclusive, thus allowing anyone to feel welcome and contribute with confidence.
So now, only one question remains... who is confident in C and wants to submit a revolutionary patch to git? 🤩
Top comments (13)
Removing the
blamecommand 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 usesblame.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
pullbehaviour). Perhaps a first step would be drafting language for and publishing a patch to provide a message when a user typesgit blame, to suggest the alternativeannotate(or introduced alternate) and frame the user's experience better?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...
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 implementingblame.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 toblameand see that I wrote it last year!And when I read comments about how
blameexists so we know which co-worker to blame, all that person is saying to me is that they don't understand its purpose: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
blameis adequate and accurate. Usingauthoris insufficient because it doesn't accurately describe what it provides. Similarly, something likepraisedoesn'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
blameis to identify when and where bugs were introduced:fileI suspect that unlucky line13might be the cause of a bug.git blame fileagain, checking for that revision:blamethose 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
praisewould 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
blamedefine an alias in your.gitconfigto use whatever language you want:Then you can
git awesome fileinstead. It's the great thing about being computer literate, you can define your own language to interact with your machine (-; my personal favourite isgit f*ckitthat I regularly use to nuke any changes when I accept that my entire approach is wrong ;-)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 aliasas 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 blamebetter than others and as a result don't feel negatively affected by it, the naming ofgit blameis 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 blamein 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.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 blamedefining 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:
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.
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 blameor 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.git blameon 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.git aliasis not an adequate solution - it doesn't address that blame remains the default wording for an entire industry.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.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.
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 😃
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. 😅
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
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.
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.
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!
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!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.