I'm also not a fan of emoji here. Though, I do like some systematic prefixes for commits, such as the ones proposed by Conventional Commits: https://www.conventionalcommits.org/en/v1.0.0-beta.2/
Gitmoji – Yay or Nay?
11–20 of 224 posts
Re: Gitmoji – Yay or Nay?
#12I had a short discussion about them just yesterday. It’s not a yay for me but also not a nay. I use icons for change lists in pull requests and release notes. But I use my own set of svg icons to have better control over the icons themselves.
I don’t like these icons in commit message subject lines because they're too ambiguous. If you adopt the imperative subject line style (Add class X, Fix issue XYZ, etc.) you have all the same benefits plus a clearer meaning. Also using a emoji plus a description like ‘:bug: fixes issue’ makes the whole benefit of short one character icons go away.
Re: Gitmoji – Yay or Nay?
#13I was about to go in fully to this style at most ~2 weeks ago. It's another forcing function to be cognizant of what exactly you're working on at a given time. (Speaking from JavaScript land,) don't update the packages, fix two bugs, add a couple features, refactor some code all in the same commit. When things go wrong in a few months, your bisect will land right on that big blob of things. In the vein of focusing on…
Instead of grep for :sparkles: etc you can also just grep for any other prefix style. The biggest turn down for me is the fact that these emojis render differently on each platform. It’s hard to transpose meaning for an icon that is not static in its visual.
Re: Gitmoji – Yay or Nay?
#14> 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.
Plus the benefit of not being ambiguous like a lipstick emoji :)
Re: Gitmoji – Yay or Nay?
#15Definetely 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.
Re: Gitmoji – Yay or Nay?
#16That'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. T…
> Emoji are hard to type on non-mobile platforms
On Windows they are easy: + .
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.
Re: Gitmoji – Yay or Nay?
#17Why 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:).
Re: Gitmoji – Yay or Nay?
#18That'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. T…
> Emoji are hard to type on non-mobile platforms On Windows they are easy: + . 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.
Mac equivalent is Cmd + Ctrl + Space (Edit > Emoji and Symbols).
Re: Gitmoji – Yay or Nay?
#19Couldn't something text based ( like this[1] ) be standardized much easily?
1: https://gist.github.com/abravalheri/34aeb7b18d61392251a2
ed. I see another comment points to the conventionalcommits proposal.
Re: Gitmoji – Yay or Nay?
#20That'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. T…
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.