git log --pretty=oneline --abbrev-commit | grep "\[doc"
Emojis feel... complicated. What do they mean? Here you're just typing the literal word so not much to remember or search.
:rotating_light: Lint
Why not just use "[rotating_light] Lint" as the commit message? Or even better: "[lint] Make changes recommended by foo lint\n\nThis is the foo command used: ..."
My first smartphone was a Galaxy S2, and I frequently used an emoji that looked like a character giving a sly winking-type gesture.
It took me several years to realize that this was actually the eye-rolling emoji, and every other system's implantation clearly showed this. Some of the more strange responses I received started to make sense.
Most browsers would highlight all the matches.
On top of that, emojis are much less friendly to visually impaired people.
[ticket-type]/#TICKET-[ticket-description]
bug/APP-123-prevent-auth-redirect-loop
The emoji thing is fine if it's for fun - we should all enjoy ourselves and our work a little more - but I'm hard pressed to see the practicality of it.
The first thing that comes to mind is that it takes up less space and is thus easier to scan. Also, people with visual impairments may have an easier time scanning based on color/shape rather than reading each individual line.
Also, it's just as easy to grep for ':bug:' than 'bug', or rather, it's more specific to do so. Likewise, people suggesting [bug] have to worry about whether their shell or grep is going to interpret the square brackets (they will).
git log | grep '[bug]' - does not do what you want
git log | grep [bug] - fails in ZSH; works as above in bash
git log | grep bug - matches lots of things, not just the tag
git log | grep ^bug - Doesn't work because 'git log' puts spaces in front of commit lines
git log | grep :bug: - Does exactly what you expect it to and nothing else.
That's the practicality that I see, personally.
> you don't need to worry about emojis rendering differently on different platforms
You don't really need to worry about that anyway, as long as you're generally on the same one or two platforms. A user on Ubuntu will always see the same bug, even if :bug: gives them a different bug illustration than an iOS user sees. In the git commits, it's represented as the tag (:bug:) and not the literal emoji.
Lastly, I fail to see anything that has to do with branching strategy with regards to emoji. This is purely commit messages and (in this case) the readme. Your branching strategy doesn't tell us anything about individual commits.
No, but this does work:
git log --grep ^bugImagine trying to handle a production incident, going through such a changelog, reading "HAHA WHOOPS LIL SHINKWRAP ISSUE THERE LOL".
>
I'm not a fan.
Edit: The emoji I added to the above message was stripped by HN's submission system.
One more reason to love HN
| ٧ | ٦ | ٥ | ٤ | ٣ | ٢ | ١ |
Win-win
I certainly find many (almost all?) highly ambiguous, which is the total opposite of expressive in my opinion.
I'm aware I will sound "old man shouts at cloud" to some, but if you need emojis to express yourself, you are lacking language skills.
I personally think that first part of the readme made good use of them and kinda helped me navigate the different sections, but they're very distracting in the commit messages, H1s and the description.
Not every line needs an emoji at the beginning or end, and IMO rarely does it need both.
Emojis in text IMO are like jokes in movies. The funnest movies have them, they're placed well and they're effective. Other movies have so many of them they just pull you from the story and then you just can't relate.
Tag with [tag], use consistent spacing etc. and, make it easy on the eyes.
Same with glorified .bashrc files used to create graphic-git command prompts.
My native language also requires unicode characters to type correctly, and they create the same problems hence, I also prefer avoiding these characters.
These are my preferences, I cannot (and should not) stop the progress. However for me, simplicity and practicality is much better than fanciness.
I'd not fight over this stuff if I was contributing to a project which embraces these concepts and play along without any fuss or objection but, I won't use these in my own projects.
I'm wondering if you're referring to a different project that you've seen and were just reminded of it, or if you're exaggerating because you saw something you didn't like.
Also, using visual indicators is nothing new; Jenkins uses thunderstorms and suns to denote build status, and marketing pages are often full of images, icons, and iconography.
The reality is, the younger generation communicates differently than the older generation, and different subcultures communicate differently from each other. Maybe you take someone less seriously because of the way they communicate, but that's on you, not on them.
All said I don't like the name because it puts Postman in a tough situation, keep the gender pronoun if you want just don't make it near identical to them.
Seems like it's doing the same thing here, I kind of hope to see more of it!