4 ms·

When emoji use follows a strict convention (something like https://gitmoji.carloscuesta.me/ https://gitmoji.carloscuesta.me/), it can make it easier to scan a l

When emoji use follows a strict convention (something like https://gitmoji.carloscuesta.me/ https://gitmoji.carloscuesta.me/), it can make it easier to scan a list of commits and get a rough idea of where the development focus is (i.e., hardening vs. feature development).

deleted 7y ago
[deleted]
aylmao 7y ago
I've seen this convention before. I personally find it more useful to tag commit messages with [fix], [docs], etc. It makes it more easily searchable, which is IMO what you really want. You can: git log --pretty=oneline --abbrev-commit | grep "\[doc" to see documentation commits, and count them by piping to `wc`. Emojis feel... complicated. What do they mean? Here you're just typing the literal word so not much to remember or search.
- wehrkeoruw 7y ago
  You can't search by arbitrary Unicode characters?
  - cbsks 7y ago
    It isn't unicode. I cloned the repo, this is the commit message in the command line: :rotating_light: Lint Here's the same commit in GitHub: https://github.com/liyasthomas/postwoman/commit/4c9c9a22406141f0b63f4f13b6b7e589dd8f74bb https://github.com/liyasthomas/postwoman/commit/4c9c9a224061... 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: ..."
- dkarl 7y ago
  Using emojis feels a bit cliquey, in-groupy. It's an extra barrier to a new developer wanting to get familiar with the project or contribute a quick fix. And you know people are going to get emojis mixed up because different associatons come to mind for different people, so project committers are going to have to be diligent about noticing and correcting mistakes. For me, the effect is the opposite of the casual and inviting atmosphere I think they're intended to create.
- dgzl 7y ago
  >Emojis feel... complicated. What do they mean? 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.
gatherhunterer 7y ago
That is far too much vocabulary to use effectively. A single-word designation would be much easier to discern and easier to translate. A word can be translated in a way that is meaningful but the “obvious” associations of the emojis may not make any sense in the context of a different language. Replacing language with inscrutable symbolism is bad design.
ijustwanttovote 7y ago
Easier to glance at an emoji than a commit message. Thanks for this guide.
- ben_jones 7y ago
  Emojis look different on different operating systems (and sometimes don't even render)...
Ayesh 7y ago
I really would like to see how Linus would react to a PR with commit messages like this.
eeZah7Ux 7y ago
A simple text string would be much faster to search in a browser or command line. Most browsers would highlight all the matches. On top of that, emojis are much less friendly to visually impaired people.
steve_adams_86 7y ago
I've been using the same branching strategy for about 5 years, and it has worked really well. I suspect it's fairly common, although everywhere I've worked we've switched to this from something with less structure. Essentially the branch naming pattern looks like: [ticket-type]/#TICKET-[ticket-description] In practice it might look like: bug/APP-123-prevent-auth-redirect-loop It makes it so you can easily automate ticket statuses with commits and merges, grep for types of issues without needing to type/remember an emoji, and you don't need to worry about emojis rendering differently on different platforms. The text will always be the same. 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.
- danudey 7y ago
  > 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.
  - thephyber 7y ago

deleted 7y ago

[deleted]

aylmao 7y ago

I've seen this convention before. I personally find it more useful to tag commit messages with [fix], [docs], etc. It makes it more easily searchable, which is IMO what you really want. You can: git log --pretty=oneline --abbrev-commit | grep "\[doc" to see documentation commits, and count them by piping to `wc`. Emojis feel... complicated. What do they mean? Here you're just typing the literal word so not much to remember or search.

wehrkeoruw 7y ago
You can't search by arbitrary Unicode characters?
- cbsks 7y ago
  It isn't unicode. I cloned the repo, this is the commit message in the command line: :rotating_light: Lint Here's the same commit in GitHub: https://github.com/liyasthomas/postwoman/commit/4c9c9a22406141f0b63f4f13b6b7e589dd8f74bb https://github.com/liyasthomas/postwoman/commit/4c9c9a224061... 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: ..."
dkarl 7y ago
Using emojis feels a bit cliquey, in-groupy. It's an extra barrier to a new developer wanting to get familiar with the project or contribute a quick fix. And you know people are going to get emojis mixed up because different associatons come to mind for different people, so project committers are going to have to be diligent about noticing and correcting mistakes. For me, the effect is the opposite of the casual and inviting atmosphere I think they're intended to create.
dgzl 7y ago
>Emojis feel... complicated. What do they mean? 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.

gatherhunterer 7y ago

That is far too much vocabulary to use effectively. A single-word designation would be much easier to discern and easier to translate. A word can be translated in a way that is meaningful but the “obvious” associations of the emojis may not make any sense in the context of a different language. Replacing language with inscrutable symbolism is bad design.

ijustwanttovote 7y ago

Easier to glance at an emoji than a commit message. Thanks for this guide.

ben_jones 7y ago
Emojis look different on different operating systems (and sometimes don't even render)...

Ayesh 7y ago

I really would like to see how Linus would react to a PR with commit messages like this.

eeZah7Ux 7y ago

A simple text string would be much faster to search in a browser or command line. Most browsers would highlight all the matches. On top of that, emojis are much less friendly to visually impaired people.

steve_adams_86 7y ago

I've been using the same branching strategy for about 5 years, and it has worked really well. I suspect it's fairly common, although everywhere I've worked we've switched to this from something with less structure. Essentially the branch naming pattern looks like: [ticket-type]/#TICKET-[ticket-description] In practice it might look like: bug/APP-123-prevent-auth-redirect-loop It makes it so you can easily automate ticket statuses with commits and merges, grep for types of issues without needing to type/remember an emoji, and you don't need to worry about emojis rendering differently on different platforms. The text will always be the same. 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.

danudey 7y ago
> 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.
- thephyber 7y ago