Nov 9, 2015 Tags: rant
Whenever I explore GitHub, I regularly come across repositories that look like this:
(I’m not bashing this particular repository or maintainer - it’s just the first example I found.)
Apart from the fact that these commit messages literally tell me nothing about
the changes they create, they also look like this in my git show:
What is :sunrise: supposed to mean to me?
Now I’m missing both an explanation of the changes and the cute little
image, which, while not very helpful in the first place, was certainly more
helpful than “:sunrise:”.
Using emoji outside of the GitHub ecosystem (that is, outside of issues and PRs) causes the following:
git-only users to understand your commits.
“:art: :hammer: words”
means absolutely nothing to me, nor does
“:arrow_up: apm.”
This makes it harder for non-GitHub users to use and contribute to your
projects.git logs and records harder to consume programmatically, defeating
the Unix-y goodness of the git ecosystem.:tada: simply doesn’t cut it.In the larger GitHub ecosystem, I don’t really mind the use of emoji. I even use them in issues and PRs - they keep things concise and light-spirited.
However, when it comes to commits, they don’t serve any real purpose (unless
your purpose it to make your commit history unreadable to anybody not solely
using a graphical web browser to interact with git).
This also goes for other silly stuff that people put in their commit
messages - ASCII/text art,
zalgo text,
and so on. My rule of thumb is trivial parseability with any of the standard
text filtering utilities - grep, sed, and/or awk. If that isn’t possible,
its value in a commit message is questionable.
I doubt that this practice is going to change anytime soon, but putting this short rant out there allows me to say “told you so” if and when it does.
- William
Afternotes:
[0] - This point doesn’t apply to small or personal projects - I’m not really concerned with the detail you put into commits on your configuration file repo.