Some people use emojis in commit messages.
Are you for ✅ or against ❌ this practice?
Why?
For further actions, you may consider blocking this person and/or reporting abuse
Some people use emojis in commit messages.
Are you for ✅ or against ❌ this practice?
Why?
For further actions, you may consider blocking this person and/or reporting abuse
Antonio | CEO at Litlyx.com -
Ben Halpern -
Ben Halpern -
Scofield Idehen -
Top comments (13)
No.
Because they're difficult to interpret, culture- and background-dependent, and all but impossible to search or filter by.
The long and short of it is, you need to use words to explain what's going on anyway, so all emoji do is add bling.
That bling can end up being inappropriate for the context - for instance, an "ok" hand having completely different meanings in different countries. A water pistol on an Apple device is a deadly weapon on another. When you see a flame, does it mean the mood is "fire" (good) or "this is fine meme" (dangerous), or "breaking change" (bad)?
If you're keeping a subject line to 80 characters so it'll work in things like emails... will the emoji count as multi-byte?
Don't make me zoom my entire viewport to figure out whether you're showing me a badger or a bear.
Don't make screen reader users listen to "hotfix 12.73.1 add gender and sport to form man brown skin tone holding flag woman light skin tone dancing canoe canoe man holding football".
Emoji aren't part of the language - any language - and there's no convenient dictionary where you can look up three blobs and a squirrel and figure out their relevance.
❌ I've tried it and I find Conventional Commits to be much clearer. Everyone thinks their choices of emojis are obvious, yet nearly every list of emoji to commit type I've seen is different. Add on top that emojis don't share a consistent look across devices and the whole thing becomes a non-starter to me.
You rely on the potential viewer's system to support them. Dealing with git on the command line, there is a very good chance that extended UTF8 characters are NOT supported. Do you want to exclude information and context from these users? What about tools built on top of Git? Do all of them support extended UTF8? This is fundamentally a UX/UI issue, excluding those not in the same ecosystem as you.
Good points here
I'd have to try and see what they look like in the CLI version of git (probably just the raw markdown which would be fine) and gitkraken (my favoured git client). Even so I would not ever encourage flippant use of them, but I find emojis actually handy for categorization - a bit like tags.
Ben Sinclair finds they are all but impossible to search and filter by which is a sound word of warning. Though I wonder why that is so, if searches and filters are on the raw markdown, so you can search for
:bug:and not 🐛. They could operate like tags when used prudently, that compress into identifiable icons in some contexts.But to be honest if they work well like that and don't get in the way of cli use or other clients I fully expect they'll just become more and more usually and widely used. Collectively, we vote by adoption or not.
❌ I would agree with those who say no (except in tight knit group of friends). As has been noted, due to differences in culture and background, emojis mean widely different things to different people. Because they tend to elicit strong emotional response, people will be more likely to attach an emotional meaning that may not be there. (Like how you may tend to read emotion from emails or texts. Was that simple "ok" from my coworker an energetic affirmation, or a sulking sarcastic reply??? Hard to say sometimes, even if you know them well!) It's best to keep it professional imo, with the language as neutral as possible. But I'll use an emoji here. 😄 Great discussion!
For public contributions on Open Source projects I would say ❌, but I've used emojis in my personal projects and with a team, and we like it a lot, I think it creates a "happy environment", there's not just text, we have emojis that represents pre-defined things, so ✅.
✅
Personal project: Maybe. I don't use it but I don't mind anyone uses it.
Open source: No, it is easier to use conventional commit. Even a weak one.
Team: Maybe. I prefer not to use it but I am fine with teammate decision.
✅
Why am I not surprised. I can't really say. I've never done this or seen it. I lean towards no because I don't know how it could be useful.