That's a no from me. I am not a huge fan of emoji. Especially not in the cli or editor.
Emoji are hard to type on non-mobile platforms, and are difficult to search for in logs or files. Often they don't render properly. They're near impossible to deal with from the command-line.
Not to mention the accessibility issues.
I see no reason why these cannot be accomplished with tags/flairs such as [critical], [bug], etc. These would also make sense to those not familiar with the Gitmoji system.
Don't make stuff harder than it needs to be. Emoji look flashy, but that's about it. Please use good ol' plaintext.
I want to emphasize on that. Why do programmers like plaintext, often to the point of wanting ASCII instead of unicode despite its international awesomeness?
That's because we are called when things break down in the machinery. Monospace ASCII may look boring, but it has a precious characteristic: there is (almost) 1-to-1 mapping between the inner representation of a character and its screen representation.
Most programming fonts make sure 1 l | i I all look different.
We make sure we can spot the difference between `'"
We know of the few remaining pitfalls, like space and tabs, \n and \r, the various escape characters, the infamous \0.
Even on that limited representation, there are many things to be careful of. And thing is: this representation is just the start of our work! all the rest hinge on that!
Unicode is full of invisible character, potential diacritics, similar-looking glyps, control character that can break the display in a lot of annoying ways.
We made a whole ASCII-based ecosystem because this mapping is precious in many debugging cases. Whatever one does in the (and I say that non-sarcastically) really wonderful and awesome world of unicode, remember that we are going to often only see it as a bunch of 0xF0 0x9F 0x92 0xA9 (<- ASCII rendition of the "pile of poo"" emoji).
Emoji are great to make some apps prettier, some chat concise, to add non verbal communication to online chat. They are not a tool to help developers' life.
Wait, I thought the goal of it is not to write emojis per se but rather use the shortcodes. That way, it's readable even when emojis cannot be rendered and it even makes search easier. So a typical commit message would read like that:
`:bug: Fix login modal`
It doesn't break anything and when interpreted (github, gitlab, gitkraken, etc...) it displays a nice looking emoji.
Finding the right emoji is easier than on my Android phone as Windows lets me type the emoji name. Why emoji search is missing on Android... who knows.
Cmd+Ctrl+Space brings up the emoji palette on MacOS. This palette is easy to use from the keyboard and works in the terminal too.
Some MacBooks famously also have a TouchBar that makes emoji easy to type.
I can't remember the last time I had issues rendering emoji, and I have no idea why they'd be difficult to search for or how they would pose any accessibility issues.
On macOS, emojis are actually easier: Control+Command+Space in any text field, then type a word to filter/search the emoji list [0], or expand the popup to a full-blown Unicode browser [1].
Emoji are hard to type on non-mobile platforms, and are difficult to search for in logs or files. Often they don't render properly. They're near impossible to deal with from the command-line.
While I agree that emoji shouldn't be used in git, it's worth noting that the limitations you point out are platform-specific, and not universal.
in macOS, emoji work very well in any app that chooses to allow them, including the terminal. Typing emoji is as simple as double-clicking on the character you want from the pane that pops down from the menu bar.
Linux may not have first-class support for emoji, and Windows may not have first-class support for emoji. But those are limitations of the operating systems, and not of the emoji, themselves.
Why do people feel the need to standardize these things?
Emoji used occasionally are fun and refreshing and can draw attention to important commits. Emoji used by default become line noise.
To paraphrase Goodhart’s Law, when a joke becomes a standard it ceases to be fun.
I also object to the details of the categorization. Some tags split up tasks that really should be done together (eg fixing bugs and updating tests, or adding features and writing docs) and some tags are duplicates (eg :art: and :recycle:).
> Why do people feel the need to standardize these things?
I'm of the opinion that these kinds of silly arguments seem to be made by people who like hearing themselves talk. They want their name on something. They want to feel like they were a part of something. It's all ego. The rest of us are happy with pragmatism and archaic things like text, which is made of glyphs which form words which we speak.
> With gitmoji others or your future self can simply look at the associated emoji and straightaway catch the intention.
Just like a word does.
> The [bug emoji] emoji is easily recognized as a bug by most people
The word "bug" works for me.
> but will [tulip emoji] immediately signalize that code is removed?
Nope. Besides, we already have commonly used symbols for that, "+" for a line added and "-" for a line deleted. I'm not sure what a tulip has to do with deleting code.
edit: hackernews removed the emoji from my post. (I put in the words for the images.) Another reason to not use emoji.
I don't like text that looks differently for everyone depending on the platform they're on.
Emojis have shown us already that vendors are willing to change their appearance depending on current trends or political climate. Gun becomes water gun, salad becomes vegan salad. One day, if caterpillar becomes a butterfly because of some mundane idea, is it still going to be instantly recognizable as a bug?
We write code in formal languages rather than natural ones to stay away from ambiguity. Emojis are a straight downgrade.
I've gotten into arguments over whether or not emoji belong in the unicode standard at all, and I'm not going to rehash them here.
What I am going to say is that regardless of whether or not emoji are a good fit for unicode, they don't degrade gracefully for blind users (or for sighted users on older hardware) and they're prone to rendering issues between different fonts that can mask intent.[0]
Everything bad about icon fonts also applies to emoji. All of the articles you've ever read about how svg icons are preferred[1] -- all of them apply to emoji as well.
So in general, I only use unicode emoji[2] if two things are true
A) I'm in a closed conversation that won't be copied and pasted around or shared publicly.
B) I know the exact platform that my reader will be using to view my text.
I don't think Git falls into either of those categories.[3]
[2]: I do heavily use emoji shorthands (:bug: :cat_eating_avacodo:) but these don't suffer from most of the same problems as emoji. They work as progressive enhancements for the platforms that render them, and fall back to readable text on the platforms that don't.
[3]: It's true that unicode fonts in general have issues when you get into non-English languages, but I don't advise people to avoid, say, Chinese characters, because: A) language glyphs don't change often enough to frighten me on accessibility, B) people who need to see them are likely already using devices that support their own languages, and C) we don't have a good alternative we could use instead.
why not? there is a canonical plain-text description for every unicode emoji. at least in theory, i see no reason why a screen reader shouldn't be able to handle emojis.
> they don't degrade gracefully for blind users (or for sighted users on older hardware)
It irks me when people, including blind people, advocate against something on accessibility grounds when it's something that current screen readers can handle perfectly well. Another example of this would be saying that JavaScript-dependent sites are inherently inaccessible. We should save our accessibility advocacy for things that are actually problems.
The fact is that if we assume that people want to use little pictures to communicate, then exactly because emoji is part of the Unicode standard, we should encourage its use, as opposed to, say, graphics that may or may not have alt text.
Definetely a no for me. I also hate seeing commit message littering with emoji and feel like the author is too lazy to find correct words. I also disagree with the "visual cue" advantage, because the emoji looks different per machine/font/terminal/OS. Plain text looks consistent every where.
> Forces you to make smaller and more specific commits
There's no forcing anyone to make smaller and specific commits. It may be used as a reminder, or tool, but certainly not going to prevent someone from committing junk behind whatever emoji they choose.
Not to mention that a non-emoji based tagging scheme (e.g. “[bug]”, “[UI]”, etc.) would likely have the same effect (if there is any) that the author purports.
Absolutely not. Keep your emojis out of my CLI and my face, even, as far as professional areas of life are concerned. I see READMEs full of emojis, the description of the project is full of emojis... I personally dislike it, and it actually makes me reconsider digging more into that project. I might have prejudices, but it is quite childish to me. The only place where I am fine with emojis is instant messaging applications (for casual conversations). You can even have stickers there if you want for all I care!
Because it relies on a lot of cultural background. Which in the world of emoji changes fast. This won't be welcoming of new users when they have to learn 10 or more symbols for whatever you're doing.
:lipstick: for UI changes? Why? :computer: or :smartphone: as those are the usual interface used or ️:wheelchair: because you care about something accessible would feel better.
If we could have :pig: as well, we could at least do :lipstick::pig: for kludges on bad code...
I think you're right on the mark about the strong cultural context and arbitrariness of the symbols.
The value I see in emoji for this sort of application (as others have also pointed out here) is for jokes and maybe (rarely) highlighting lines visually. Obviously the joke dies if the use gets standardized, and the practical disadvantages far outweigh the advantages.
Nay! Emoji is slang that excludes a huge number of people, not just due to preference but also because the meaning keeps changing and can be confusing if not exhausting to keep up with. It skews young and/or Western and there's far more kinds of programmers than that.
If we cannot describe in the subject what we are doing, we should not commit it.
Icons are perfect to define actions (fixing bugs, improving the layout, etc) however, the commit is important when you are doing releases, cherry-picks, maintaining patches, etc.
I'm not against changes and sure the icons look very cool on the front page of GitHub or in `git log`.
However, most of the maintainers, who actually do things with commits, they work looking at the content. Be useful in the future, to understand what was going on, is the main purpose of the commit message.
I agree that a bug, a rocket (and others) can be used to improve the subject of a commit, eventually, the problems are:
-by introducing icons, are we creating a perfect excuse to be lazy during the commit phase?
-Will the icons makes our history of change the poorest?
Apparently Ubuntu 18.04 introduced native emoji support through bundling Google's Noto Colour emoji font and an emoji picker ui built into Gnome. Looks very similar to MacOS's built in emoji picker that I'm used to.
I'd rather not but not because of the emoji but because atm I don't like categorizing commits in the first place. I've just tried doing it on a project and it felt pretty weird. Instead of just grouping single atomic changes like I'd usually do, I suddenly also have to think about what category fits a commit best and what to do if a commit satisfies multiple categories.
Thinking about it, emoji could actually help with this since it's easier to assign multiple categories to a commit without wasting a lot of character space. Still, what I'd rather want to see become a convention is an annotation in the commit's body that simply marks whether it's a major/minor/patch bump (or none). Plus optionally a line for the changelog. (Optionally because it allows commits to stay small while also not cluttering the changelog.)
- you can glance the commit log wall of text and still get a lot of info, not something you can do with other forms
I don't like textual representation tho (i.e. :zap: vs :feature: ) and if u watch log in systems that can't present images it might be actually harder to understand
macOS VoiceOver reads one of the (but not necessarily the most useful in a given context) names of the emoji. For example, gets read as “caterpillar”. However, importantly: there’s no distinction that it’s an emoji when read.
Caveats: I have no idea what JAWS does here. I’m not a visually impaired user, but have done a11y work in the past.
I have tried to use Gitmoji and other standards before on a few projects but I have since stopped. The motivation behind it makes a lot of sense but I can count the number of instances where I have used the emojis as a cue to find problematic commits with one hand.
That being said, I never really thought about the point about forcing you to ensure your commit is atomic. I definitely have become better at it but the habit has stuck even after using Gitmoji.
[+] [-] rahuldottech|6 years ago|reply
Emoji are hard to type on non-mobile platforms, and are difficult to search for in logs or files. Often they don't render properly. They're near impossible to deal with from the command-line.
Not to mention the accessibility issues.
I see no reason why these cannot be accomplished with tags/flairs such as [critical], [bug], etc. These would also make sense to those not familiar with the Gitmoji system.
Don't make stuff harder than it needs to be. Emoji look flashy, but that's about it. Please use good ol' plaintext.
[+] [-] Iv|6 years ago|reply
I want to emphasize on that. Why do programmers like plaintext, often to the point of wanting ASCII instead of unicode despite its international awesomeness?
That's because we are called when things break down in the machinery. Monospace ASCII may look boring, but it has a precious characteristic: there is (almost) 1-to-1 mapping between the inner representation of a character and its screen representation.
Most programming fonts make sure 1 l | i I all look different.
We make sure we can spot the difference between `'"
We know of the few remaining pitfalls, like space and tabs, \n and \r, the various escape characters, the infamous \0.
Even on that limited representation, there are many things to be careful of. And thing is: this representation is just the start of our work! all the rest hinge on that!
Unicode is full of invisible character, potential diacritics, similar-looking glyps, control character that can break the display in a lot of annoying ways.
We made a whole ASCII-based ecosystem because this mapping is precious in many debugging cases. Whatever one does in the (and I say that non-sarcastically) really wonderful and awesome world of unicode, remember that we are going to often only see it as a bunch of 0xF0 0x9F 0x92 0xA9 (<- ASCII rendition of the "pile of poo"" emoji).
Emoji are great to make some apps prettier, some chat concise, to add non verbal communication to online chat. They are not a tool to help developers' life.
[+] [-] fbnlsr|6 years ago|reply
`:bug: Fix login modal`
It doesn't break anything and when interpreted (github, gitlab, gitkraken, etc...) it displays a nice looking emoji.
[+] [-] porker|6 years ago|reply
On Windows they are easy: <Windows key> + .
Finding the right emoji is easier than on my Android phone as Windows lets me type the emoji name. Why emoji search is missing on Android... who knows.
[+] [-] bluerobotcat|6 years ago|reply
Some MacBooks famously also have a TouchBar that makes emoji easy to type.
I can't remember the last time I had issues rendering emoji, and I have no idea why they'd be difficult to search for or how they would pose any accessibility issues.
[+] [-] chrisseaton|6 years ago|reply
They are plaintext. They’re Unicode characters just like abc. There’s nothing special about them!
[+] [-] oselhn|6 years ago|reply
[+] [-] Razengan|6 years ago|reply
On macOS, emojis are actually easier: Control+Command+Space in any text field, then type a word to filter/search the emoji list [0], or expand the popup to a full-blown Unicode browser [1].
[0] https://i.imgur.com/ZpAcIe3.png
[1] https://i.imgur.com/uN9fxmH.png
[+] [-] reaperducer|6 years ago|reply
While I agree that emoji shouldn't be used in git, it's worth noting that the limitations you point out are platform-specific, and not universal.
in macOS, emoji work very well in any app that chooses to allow them, including the terminal. Typing emoji is as simple as double-clicking on the character you want from the pane that pops down from the menu bar.
Linux may not have first-class support for emoji, and Windows may not have first-class support for emoji. But those are limitations of the operating systems, and not of the emoji, themselves.
[+] [-] greggman2|6 years ago|reply
I generally find those against emoji to be unintentionally racist since other cultures have been using various characters for decades if not longer
[+] [-] iainmerrick|6 years ago|reply
Emoji used occasionally are fun and refreshing and can draw attention to important commits. Emoji used by default become line noise.
To paraphrase Goodhart’s Law, when a joke becomes a standard it ceases to be fun.
I also object to the details of the categorization. Some tags split up tasks that really should be done together (eg fixing bugs and updating tests, or adding features and writing docs) and some tags are duplicates (eg :art: and :recycle:).
[+] [-] MisterTea|6 years ago|reply
I'm of the opinion that these kinds of silly arguments seem to be made by people who like hearing themselves talk. They want their name on something. They want to feel like they were a part of something. It's all ego. The rest of us are happy with pragmatism and archaic things like text, which is made of glyphs which form words which we speak.
[+] [-] bluntfang|6 years ago|reply
Really? Because standardization leads to automation.
[+] [-] WalterBright|6 years ago|reply
Just like a word does.
> The [bug emoji] emoji is easily recognized as a bug by most people
The word "bug" works for me.
> but will [tulip emoji] immediately signalize that code is removed?
Nope. Besides, we already have commonly used symbols for that, "+" for a line added and "-" for a line deleted. I'm not sure what a tulip has to do with deleting code.
edit: hackernews removed the emoji from my post. (I put in the words for the images.) Another reason to not use emoji.
[+] [-] zyx321|6 years ago|reply
I strongly suspect it's related to my first language being German, which maps "bug" and "beetle" to the same word "Käfer".
[+] [-] Aeolun|6 years ago|reply
Is that what it looks like for you? For me it’s a flame (which seems to make more sense for removing code).
[+] [-] cryptonector|6 years ago|reply
[+] [-] tadzik_|6 years ago|reply
I don't like text that looks differently for everyone depending on the platform they're on.
Emojis have shown us already that vendors are willing to change their appearance depending on current trends or political climate. Gun becomes water gun, salad becomes vegan salad. One day, if caterpillar becomes a butterfly because of some mundane idea, is it still going to be instantly recognizable as a bug?
We write code in formal languages rather than natural ones to stay away from ambiguity. Emojis are a straight downgrade.
[+] [-] UserIsUnused|6 years ago|reply
I think this is the most important point of it all.
[+] [-] chrisseaton|6 years ago|reply
But we already have fonts that make the Latin alphabet look different on different platforms.
> if caterpillar becomes a butterfly because of some mundane idea, is it still going to be instantly recognizable as a bug?
Yes? Didn’t Hopper tape a moth ‘bug’ into her notebook?
[+] [-] danShumway|6 years ago|reply
What I am going to say is that regardless of whether or not emoji are a good fit for unicode, they don't degrade gracefully for blind users (or for sighted users on older hardware) and they're prone to rendering issues between different fonts that can mask intent.[0]
Everything bad about icon fonts also applies to emoji. All of the articles you've ever read about how svg icons are preferred[1] -- all of them apply to emoji as well.
So in general, I only use unicode emoji[2] if two things are true
A) I'm in a closed conversation that won't be copied and pasted around or shared publicly.
B) I know the exact platform that my reader will be using to view my text.
I don't think Git falls into either of those categories.[3]
[0]: https://blog.emojipedia.org/apple-and-the-gun-emoji/
[1]: https://cloudfour.com/thinks/seriously-dont-use-icon-fonts/
[2]: I do heavily use emoji shorthands (:bug: :cat_eating_avacodo:) but these don't suffer from most of the same problems as emoji. They work as progressive enhancements for the platforms that render them, and fall back to readable text on the platforms that don't.
[3]: It's true that unicode fonts in general have issues when you get into non-English languages, but I don't advise people to avoid, say, Chinese characters, because: A) language glyphs don't change often enough to frighten me on accessibility, B) people who need to see them are likely already using devices that support their own languages, and C) we don't have a good alternative we could use instead.
[+] [-] woodrowbarlow|6 years ago|reply
why not? there is a canonical plain-text description for every unicode emoji. at least in theory, i see no reason why a screen reader shouldn't be able to handle emojis.
[+] [-] mwcampbell|6 years ago|reply
It irks me when people, including blind people, advocate against something on accessibility grounds when it's something that current screen readers can handle perfectly well. Another example of this would be saying that JavaScript-dependent sites are inherently inaccessible. We should save our accessibility advocacy for things that are actually problems.
The fact is that if we assume that people want to use little pictures to communicate, then exactly because emoji is part of the Unicode standard, we should encourage its use, as opposed to, say, graphics that may or may not have alt text.
[+] [-] letientai299|6 years ago|reply
[+] [-] kfrzcode|6 years ago|reply
There's no forcing anyone to make smaller and specific commits. It may be used as a reminder, or tool, but certainly not going to prevent someone from committing junk behind whatever emoji they choose.
[+] [-] amarshall|6 years ago|reply
[+] [-] gitgud|6 years ago|reply
This seemed like a negative point to me, I envisioned "smaller" commit messages purely of emoji's ..... :(
[+] [-] johnisgood|6 years ago|reply
[+] [-] arkh|6 years ago|reply
> A picture says more than words
Because it relies on a lot of cultural background. Which in the world of emoji changes fast. This won't be welcoming of new users when they have to learn 10 or more symbols for whatever you're doing.
:lipstick: for UI changes? Why? :computer: or :smartphone: as those are the usual interface used or ️:wheelchair: because you care about something accessible would feel better.
[+] [-] etiam|6 years ago|reply
I think you're right on the mark about the strong cultural context and arbitrariness of the symbols. The value I see in emoji for this sort of application (as others have also pointed out here) is for jokes and maybe (rarely) highlighting lines visually. Obviously the joke dies if the use gets standardized, and the practical disadvantages far outweigh the advantages.
[+] [-] mondaygreens|6 years ago|reply
[+] [-] kalleboo|6 years ago|reply
How does it skew Western when they were literally invented in Japan?
[+] [-] mcs_|6 years ago|reply
Icons are perfect to define actions (fixing bugs, improving the layout, etc) however, the commit is important when you are doing releases, cherry-picks, maintaining patches, etc.
I'm not against changes and sure the icons look very cool on the front page of GitHub or in `git log`.
However, most of the maintainers, who actually do things with commits, they work looking at the content. Be useful in the future, to understand what was going on, is the main purpose of the commit message.
I agree that a bug, a rocket (and others) can be used to improve the subject of a commit, eventually, the problems are:
-by introducing icons, are we creating a perfect excuse to be lazy during the commit phase?
-Will the icons makes our history of change the poorest?
[+] [-] jlillesand|6 years ago|reply
1. They add easy noticeable visual cues that might otherwise require reading a full sentence (at that often will be omitted altogether).
2. It's fun and informal, something that's often lacking in dev teams.
[+] [-] iainmerrick|6 years ago|reply
[+] [-] LockAndLol|6 years ago|reply
This is what it looks like to me:
- [CLI](http://i.imgur.com/XMcXwvi.png)
- [Pycharm](http://i.imgur.com/HOXj2yg.png)
Even displaying that recycle emoji required me to install some font from a repo on github. Emojis seem to have very poor support on linux.
If [this method](http://i.imgur.com/v5eqgSJ.png) of entry were standard then maybe it'd be interesting and I'd give it a try.
Given the current status of emoji support on linux, that's a big naw from me dawg
[+] [-] have_faith|6 years ago|reply
[+] [-] daliusd|6 years ago|reply
I don't use pycharm so I can't propose anything.
[+] [-] lwhsiao|6 years ago|reply
[+] [-] t0astbread|6 years ago|reply
Thinking about it, emoji could actually help with this since it's easier to assign multiple categories to a commit without wasting a lot of character space. Still, what I'd rather want to see become a convention is an annotation in the commit's body that simply marks whether it's a major/minor/patch bump (or none). Plus optionally a line for the changelog. (Optionally because it allows commits to stay small while also not cluttering the changelog.)
Any thoughts/feedback/etc on this?
[+] [-] wvh|6 years ago|reply
Akin to the person with the boombox on public transport.
I could imagine wanting to highlight some keywords myself – for myself – but now my screen has turned into a colourful shouting competition.
[+] [-] axegon|6 years ago|reply
[+] [-] majkinetor|6 years ago|reply
- same amount of chars to type
- single char / img to read (way faster)
- you can glance the commit log wall of text and still get a lot of info, not something you can do with other forms
I don't like textual representation tho (i.e. :zap: vs :feature: ) and if u watch log in systems that can't present images it might be actually harder to understand
That would be general yay
[+] [-] xiconfjs|6 years ago|reply
[+] [-] amarshall|6 years ago|reply
Caveats: I have no idea what JAWS does here. I’m not a visually impaired user, but have done a11y work in the past.
[+] [-] bbody|6 years ago|reply
That being said, I never really thought about the point about forcing you to ensure your commit is atomic. I definitely have become better at it but the habit has stuck even after using Gitmoji.