I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
I think this is a lot harder to read than text, and a lot harder to search for. I would never guess that "fire" meant "remove code" or that a coffin meant the same, and the different variations of things like tools and builders' hats aren't distinct enough.
This problem happens any time people try to use icons. They find one or two that seem to fit, and then run out of 1-to-1 matches so end up using generic things like "document" for everything else.
I don't relish having to search the web for something that looks like a bug emoji, copy it, paste it into my search box, and then discover than the other person working on the project used a slightly different bug.
search the web for something that looks like a bug emoji [...] other person working on the project used a slightly different bug.
This can also be true with words, bug isn't the greatest example, though. In the case of gitmoji, the icons are being defined and there is a place to search on what you might want and still remain consistent across the team.
That being said, it isn't about the icons. It isn't really about reading or searching. It encourages good separation of intent for a commit.
I have a general rule that their is on emoji per commit. If the commit should have two then the commit should be broken apart. We don't want the code refactor and feature add at the same time. Yes I do break this from time to time, but this is an exception rather than common practice.
The emoji list goes a little further then necessary, but it also provides more opportunity to identify how to separate commits.
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
Also worth noting is the gitemoji system is an extension or variation of the conventional commit system, which has fewer items. So there is less to remember and to choose from when writing messages.
Like two gitemoji choices for deleting plus the config change can go under chore for conventional commit.
And two CI choices can go under ci.
I also don't care about a separate item for "development scripts". I would put that feat or fix or refactor etc.
It depends what you agree in your team and how you are going to use it. Having granular messages (gitemoji and/or conventional commit) is useful if have a large number of commits to generate a changelog / release notes for, maybe even for end users to read to know fixes for their Android device.
But otherwise using just the conventional commit system without the emojis is fine. There is a VSCode extension which supports that word as a prefix without the emoji.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think this is a lot harder to read than text, and a lot harder to search for. I would never guess that "fire" meant "remove code" or that a coffin meant the same, and the different variations of things like tools and builders' hats aren't distinct enough.
This problem happens any time people try to use icons. They find one or two that seem to fit, and then run out of 1-to-1 matches so end up using generic things like "document" for everything else.
I don't relish having to search the web for something that looks like a bug emoji, copy it, paste it into my search box, and then discover than the other person working on the project used a slightly different bug.
I agree but also disagree.
This can also be true with words, bug isn't the greatest example, though. In the case of gitmoji, the icons are being defined and there is a place to search on what you might want and still remain consistent across the team.
That being said, it isn't about the icons. It isn't really about reading or searching. It encourages good separation of intent for a commit.
I have a general rule that their is on emoji per commit. If the commit should have two then the commit should be broken apart. We don't want the code refactor and feature add at the same time. Yes I do break this from time to time, but this is an exception rather than common practice.
The emoji list goes a little further then necessary, but it also provides more opportunity to identify how to separate commits.
I agree. I've seen other threads where someone doesn't understand what the emojis are.
I think a good middle -ground is using both. Maybe like this.
Also worth noting is the gitemoji system is an extension or variation of the conventional commit system, which has fewer items. So there is less to remember and to choose from when writing messages.
Like two gitemoji choices for deleting plus the config change can go under
chorefor conventional commit.And two CI choices can go under
ci.I also don't care about a separate item for "development scripts". I would put that feat or fix or refactor etc.
It depends what you agree in your team and how you are going to use it. Having granular messages (gitemoji and/or conventional commit) is useful if have a large number of commits to generate a changelog / release notes for, maybe even for end users to read to know fixes for their Android device.
But otherwise using just the conventional commit system without the emojis is fine. There is a VSCode extension which supports that word as a prefix without the emoji.