Gitmoji – Yay or Nay?
opensource.christmas
Gitmoji – Yay or Nay?
1–10 of 224 posts
Re: Gitmoji – Yay or Nay?
#2I recently started using emoji to name tmux windows and I find it pretty useful. That being said this is probably pretty cool too. However, I could never see myself enforcing such a thing in my flow. Let alone trying to enforce it on others. It’s a nice thing if people want to do it though.
Re: Gitmoji – Yay or Nay?
#3That'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.
Re: Gitmoji – Yay or Nay?
#4My main concern are blind people, I‘m not sure how well these emojis are accessible for them.
Re: Gitmoji – Yay or Nay?
#5Feels like a zoomer thing. I wouldn't do it for personal projects, and I wouldn't allow it for teams I lead. They seem nice on the surface, but they just become noise.
Ever install a popular node package? It barfs up a ton of emojis in my terminal.
Re: Gitmoji – Yay or Nay?
#6> 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.
Re: Gitmoji – Yay or Nay?
#7My main concern are blind people, I‘m not sure how well these emojis are accessible for them.
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.
Re: Gitmoji – Yay or Nay?
#8> 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.
Re: Gitmoji – Yay or Nay?
#9I 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 things it's also nice when reviewing code. Ideally reducing the amount of times someone sneaks in a random 'bug fix' that eventually needs to be tracked down and added to the spec.
Also, the idea of being able to categorize all commits into their respective buckets between releases. A similar idea from the other commit message prepend style out there, but with emojis. Grep for all :sparkles: and :bugs: and you have your patch notes.
But, as I started with, I couldn't commit, (heh). Terminal + `zsh` on MacOS Catalina seems to refuse to format emojis properly, often resulting in console frustrations as spaces disappear and emojis overlap text. If anyone knows a fix, let me know!
Re: Gitmoji – Yay or Nay?
#10I like it! I agree with many of the objections in other comments, but used wisely emojis in commit messages can definitely add value.
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.