Secondary Gitmoji, or what to do with 💥

[TristanCottam]

The problem

Certain Gitmoji don't represent intentions themselves, but rather give additional context to the changes made (most notably 🚧, 💩, 🍻, and 💥). Considering only the single most relevant Gitmoji should be included in a commit message, and intention is always more relevant than context, these would theoretically never be used.

Possible alternatives

• 🚧 could be by expressed through other means, e.g. branches.
• 💩 could be expressed by a TODO comment above the relevant code block.
• 🍻 is irrelevant, and in my opinion should be removed.
• 💥 is essential, and must be expressed separately from the intention of the commit.

Allowing the use of secondary Gitmoji in commits, through one way or another, would solve this problem, but such a feature is subject to discussion. However, expressing breaking changes separately from the intention is essential.

My opinion

Since breaking changes often deserve additional context, they could be expressed as a footer in the commit body, in the same way as Conventional Commits.

On a side note: the "Example of usage" (syntax specification) in README.md should include the (optional) commit body, as it is currently unclear the standard allows it.

[Thanyanit-J]

I used 🚧 when I'm about to take my day off, but my boss want to see my unfinished works. He wanted me to commit and push anyway so this emoji fit perfectly. Just make sure to remind myself to undo the commit.

But yeah, creating a new temporary branch works too, and probably better since if I accidentally include 🚧 (which I did two times), the git blame gonna looks so scary.

The commit "🚧 WIP: DO NOT MERGE" actually got merged lol. This would not happen if I created a new temporary branch.

---

For 🍻 and 💩, it's perfect for coding party, fun activity, or hackathon.

[vhoyer]

you have a good point @tristan-cottam, whenever I have to use the :boom: I usually drop any other "intention emojis", as I see the fact that something is a breaking change to be the most relevant fact of that commit, but I see you, I would be down to standardize treating BREAKING CHANGES as we do in conventional commits, seems a good solution.

Really the other three emojis haven't been removed probably due to emotional attachment to them, the one that I use the most is :construction: and I use it to fix things in previous commits, like, things that I forgot I wanted to include in a past commit, I add a :construction: then a message to remind me where I wanted to fixup that diff, and when I open the PR, I do a little git rebase in my branch to remove'em, but I digress.

[connorjs]

Regarding "secondary emoji" comment - I toss a second emoji at the end of my title when I feel a second applies.

That being said, my GitHub work seems to have second emojis in arbitrary positions, rather than last (which I believe I was more consistent with at work).

• ✅ Unit testing with Vitest: 🎉 vitest-config
• 🤡 Fake Data (and 🏷 document types)
• 🚨 ESLint: 🎉 eslint-config

I use 🎉 for new projects in monorepo

[connorjs]

@tristan-cottam - is the (primary) goal of this discussion to (a) discuss removing the mentioned emojis, (b) formalize a secondary emoji, (c) formalizing gitmoji for parsing similar to conventional commits, or something else?

[connorjs]

Regarding 🚧 - I proposed using it in https://github.com/carloscuesta/gitmoji/issues/1300#issuecomment-1481504008, so removing 🚧 would get my vote for that 🦴 gitmoji (structure/skeleton).