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?
Top comments (25)
I feel like we often look for antonyms to
blame, because that phrasing was obviously the choice of git's maker Torvalds who genuinely enjoys confrontation and condescendence.But I don't know if
praiseorcreditevenwhois what we're necessarily looking for. You're looking for details of what happened. Maybe you're looking to find that person and ask them a question, but really you're just looking for a place to start.So I think something like
git storyorgit journeyorgit taleorgit report.git if these walls could talk.Subversion uses
blametoo, and it is older than Git. So maybe this is just Linus using a common term.Wanting to see how the lines have changed over time, presumably with context, is a much harder thing to do than to show the last person who touched a line in a commit, though. I'm not saying it's a bad idea, but at that point... well, it doesn't fit in the gutter of your favourite editor anymore.
Yeah, it's usually the commit message you're after, or the commit hash that you can use to look up the whole commit.
Another possibility:
git contextI've used it to know the author more than once, so I can ask for help with a specific section of the code.
They never remember writing it...
git this old repoGit also has git annotate command, which is very similar to git blame.
And the only difference between annotate and blame is the output.
annotateshould not be used, it exists only for backwards compatibility. You can get annotate-ish output with git blame -c if you want.Webstorm uses it btw and I like it 👍
Why not just think of it as blaming the commit?
If it’s the shared source it’s the ownership of everyone, someone probably had to review that commit too.
Blame the code. :)
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.
Subversion has
blametoo, but it's an alias forpraiseandannotate(orannfor short).I presume Git took
blamefrom 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.annotateis kinda neutral, but I thinkwhois probably the best solution, because it literally answers the question, "who last touched this?"$ git shame🔔But in all seriousness,
what about
$ git owns, as in, this person has 'ownership' over this commit.This language is without the added baggage of judgement– one way or the other.
There is this VSCode plugins to let us see the
git blameinline, it is called git lens, maybegit lenswould fit it?I'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
It 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.
Actually, you want to know "who" did something, without verdict, so perhaps
git whocould be a good alternative