Tldr: Emojis in commit messages (gitmoji)

[ivanhercaz]

Dear comrades, this is a riot! No, just a joke that I need to did. I hope you don't mind.

I would like to discuss about the emojis in commits messages. Should we avoid its use?

I ask about it because @mebeim ask me to not use emojis in commits messages in https://github.com/tldr-pages/tldr/pull/3727#issuecomment-573670727 and then explained me his argues in https://github.com/tldr-pages/tldr/pull/3727#issuecomment-573769537). The first thing I want to clarify is that it isn't about me or my commits. If most of us agree to not use, avoid it or using in a different way, I will do it without any problems. I usually use gitmoji with gitmoji-cli since a few time ago because I like the graphical way to summarize/categorize the commit. But this is something I know that not all projects use and it is easy to not use because the commit message is done with gitmoji-cli and not git commit.

To summarize the opiniones given by mebeim and @zdroid in #3727: The first one said the emoji don't add useful information and it is only rendered in specific environments, and the second one said it could be at the end of the commit message to not make the commit message harder to read.

I have been using until now, but as I said, I can stop to use. So, should we avoid/don't use emojis?

[mebeim]

Thanks for opening the issue and summing up :+1:

[einverne]

I kinda agree what @mebeim said in https://github.com/tldr-pages/tldr/pull/3727#issuecomment-573769537, emoji did not add more information in commit message. And for me, I still did not know when to use the other emojis in comments (except +1/-1).

But like you said, if we can give emoji a specific purpose, like gitmoji used, it will be a nice way to try.

[ivanhercaz]

Thanks for opening the issue and summing up

Thanks to you for bringing it up, because if not it could pass but annoy the workflow of someone.

But like you said, if we can give emoji a specific purpose, like gitmoji used, it will be a nice way to try.

This would be interesting, @einverne.

[sbrl]

I'm inclined to say that it would be best to either put them at the end of the message, or have some sort of agreement as to which ones to use when.

[mebeim]

I'm copy-pasting my reply from the other thread for reference. I totally forgot that it was only linked above and not quoted.

emojis don't add any useful information in a commit message and are only rendered in a specific environment (e.g. the GitHub website), thus also making it needlessly harder to read commit messages anywhere else. Other than that, what you see as a globe here on GitHub, is really a 22 characters string which dramatically decreases the usable space of the first line of the commit message.

I would like to put the emphasis on the fact that those will only be rendered on GitHub, since we are talking specifically about gitmoji (and not Unicode emojis).

[ivanhercaz]

All comments are interesting! I read three positions in the comments written:

1. Don't use gitmoji because it doesn't add any useful information.
2. If gitmoji is used, it must be at the end of the commit message and not at the beginning.
3. Give to some emojis of gitmoji a meaning/specific purpose.

An additional question, whatever is decided, should the agreement about gitmoji be specified in the commit messages guideline?

[zlatanvasovic]

An additional question, whatever is decided, should the agreement about gitmoji be specified in the commit messages guideline?

Yes, since this is a technical project. We don't want unwritten rules.

[mebeim]

1. Give to some emojis of gitmoji a meaning/specific purpose.

This would definitely just add unneeded complexity. Accepting gitmojis and then regulating their usage? Looks like 2 problems at the price of 1 to me D:

[zlatanvasovic]

My final take on this is: it's alright to put anything you want into a commit message, as long as it isn't blocking any more important information. So, emojis are okay, but at the end of the messages.

[mebeim]

I'll take the more conservative stance here, but IMHO this is in not acceptable. As I said, emojis used this way:

1. Don't add useful information.
2. Make it needlessly harder to read commit messages in any place that is not GitHub's website.
3. Take up a significant amount of characters from the commit summary.
4. + Giving a specific purpose to emojis would mean regulating their usage, which is 2 problems at the price of 1.

I would appreciate if some other members could give a definitive take on this, since it's been open for quite a while. CC @zdroid @sbrl @agnivade @owenvoke @schneiderl @einverne

[zlatanvasovic]

@mebeim Is it a problem if it's in extended commit messages?

[owenvoke]

Like @mebeim, I agree with pretty much all 4 of those points. I feel that emojis don't particularly add much information, so I would probably go with the option of excluding them from the first commit line. That said, we do usually squash and merge so we could just remove them when merging a PR? Although I guess this applies for rebases, so perhaps exclude them. 😕 I have no strong preference either way though.

[mebeim]

@zdroid I was more concerned about the first line of the commit message, i.e. the commit summary. I don't see a problem with that (I also can't imagine using them in the extended commit description, but anyway). I wouldn't mind if they appear somewhere else.

[agnivade]

Gitmojis are just a weird convention which has special magical meaning only in a specific context. IMO, they should not be used.

Emojis are fine. But they don't really look professional in a commit title(even in the commit body). But that's just my preference. I wouldn't want to impose that as a rule.

[schneiderl]

I agree with @agnivade. It does not look professional and does not add much value to the commit messages.
IMO, they should not be used.

[zlatanvasovic]

If we resolved those concers, I think we can close the issue now. If the problem reappears somehow, we can reopen the issue.

[sbrl]

Sounds like everyone's in agreement then, in that we should not use them right now. I'll close this issue for now, but we can always re-open and continue the discussion if the situation changes.