I recently put out a question to my Twitter friends:
Liquid error: internal
I found myself using git blame
quite a bit, but that command never sat well with me.
No one likes to be "blamed" for stuff, and everyone thrives better in a blameless culture, so why have a blame command?
Word matter and play a very big role in the culture we build.
I got some great replies on Twitter, but was wondering if anyone on DEV had other aliases they liked?
Latest comments (25)
Renaming "blame" seems more like a sign of a humorless culture though 🤷
It's just a funny name, invented by a fellow coder rather than an HR person.
Have you seen the replies to that thread? In not worried about the culture going humorless... 😂
git blame
is OK, don't overthink it, it's just a command...Subversion has
blame
too, but it's an alias forpraise
andannotate
(orann
for short).I presume Git took
blame
from Subversion, but didn't bring the others along for the ride. I'd advocate having the others as aliases because it brings familiarity between VCSs, regardless of anything else.annotate
is kinda neutral, but I thinkwho
is probably the best solution, because it literally answers the question, "who last touched this?"haha this is true how
blame
is a strong word ! I proposegit who
? :) more friendlyI'm putting in my vote for git theseus
...and a bug report for not being able to have monospace formatting in links, and vice versa
How about
git down-on-it
?You're looking to go down through the history to see where the line came from.
And by the time you find out, you won't be so worried about who made the commit because you'll be smiling and singing to yourself.
git author
There is this VSCode plugins to let us see the
git blame
inline, it is called git lens, maybegit lens
would fit it?Actually, you want to know "who" did something, without verdict, so perhaps
git who
could be a good alternativeIt doesn't matter the name it will get used to laugh at other programmers.
It is an old conversation, clearly distinguishes what it does from other commands, and we could all use some humility when it comes back as us being the author.
Every programmer should appricate the value in stay consistent with convention. Making up your own terms just makes training harder for all those "intuitive" behaviors of the old system.