
Gitmoji – Yay or Nay? - henrikwm
https://opensource.christmas/2019/11
======
rahuldottech
That's a no from me. I am not a huge fan of emoji. _Especially_ not in the cli
or editor.

Emoji are hard to type on non-mobile platforms, and are difficult to search
for in logs or files. Often they don't render properly. They're near
impossible to deal with from the command-line.

Not to mention the accessibility issues.

I see no reason why these cannot be accomplished with tags/flairs such as
[critical], [bug], etc. These would also make sense to those not familiar with
the Gitmoji system.

Don't make stuff harder than it needs to be. Emoji look flashy, but that's
about it. Please use good ol' plaintext.

~~~
porker
> Emoji are hard to type on non-mobile platforms

On Windows they are easy: <Windows key> \+ .

Finding the right emoji is easier than on my Android phone as Windows lets me
type the emoji name. Why emoji search is missing on Android... who knows.

~~~
ken
That still seems much harder to me. Instead of just adding "PERF" to my commit
messages, and later grepping for "PERF", I have to pull up a separate window
each time, and remember that performance changes are indicated by a lightning
bolt.

~~~
setr
>remember that performance changes are indicated by a lightning bolt.

Tbh that's a very weak consideration, as it's ingrained through
standardization throughout the codebase. And if this is for codebases you're
not familiar with, then PERF is hardly gauranteed to.produce useful results
(it certainly isn't standard in my own codebases).

Much more dangerous is people expanding on emoji-tagging with things like
COLOR and similar VARIANTS, or an explosion of tags like being suggested in
this article, making it even harder to use/memorize the system

But worst of all is that emoji are ugly and ruin the aesthetic of anything
they come in contact with

------
iainmerrick
Why do people feel the need to standardize these things?

Emoji used occasionally are fun and refreshing and can draw attention to
important commits. Emoji used by default become line noise.

To paraphrase Goodhart’s Law, when a joke becomes a standard it ceases to be
fun.

I also object to the details of the categorization. Some tags split up tasks
that really should be done together (eg fixing bugs and updating tests, or
adding features and writing docs) and some tags are duplicates (eg :art: and
:recycle:).

~~~
bluntfang
>Why do people feel the need to standardize these things?

Really? Because standardization leads to automation.

~~~
iainmerrick
I'm not against automation in principle, but in this case you don't actually
need to standardize before you automate.

Observation: people are prefixing their commit messages with emoji!

Automation: let's group commit messages by emoji, with an "uncategorised"
bucket for emoji-less commits. Job done, that's all you need.

The "standard" that defines which emoji to use and when can evolve completely
separately. I'd argue that this standardization is actively bad, as it adds to
the learning curve when contributing to a project, stifles creativity (you may
only use these emoji in exactly these ways) and wastes time by encouraging
bikeshedding (people adding new categories, or arguing over existing
categories).

~~~
bluntfang
It only adds to the learning curve because some people are adamantly against
it, causing unneeded stress for adopting the standard.

~~~
iainmerrick
No, it adds to the learning curve because it adds new rules.

I also happen to think they are bad rules in this case, but that’s a separate
matter.

------
WalterBright
> With gitmoji others or your future self can simply look at the associated
> emoji and straightaway catch the intention.

Just like a word does.

> The [bug emoji] emoji is easily recognized as a bug by most people

The word "bug" works for me.

> but will [tulip emoji] immediately signalize that code is removed?

Nope. Besides, we already have commonly used symbols for that, "+" for a line
added and "-" for a line deleted. I'm not sure what a tulip has to do with
deleting code.

edit: hackernews removed the emoji from my post. (I put in the words for the
images.) Another reason to not use emoji.

~~~
Aeolun
> [tulip emoji]

Is that what it looks like for you? For me it’s a flame (which seems to make
more sense for removing code).

~~~
WalterBright
Yeah, it looks like a black tulip.

As for a flame, I don't associate fire with removing things. Frankly, emoji
and icons may work for _things_ but they don't and never have worked for
_actions_. Apple, for example, never did come up with an icon for "print" that
people didn't have to be told what it meant. Apple could have saved a lot of
grief by using "print" instead of the icon. (The same for "delete".)

Back in my days at Symantec, the people making the IDE worked hard to come up
with icons. They had a problem finding an icon to represent a CPU register,
and finally settled on a picture of a cash register.

~~~
machello13
> Apple, for example, never did come up with an icon for "print" that people
> didn't have to be told what it meant. Apple could have saved a lot of grief
> by using "print" instead of the icon. (The same for "delete".)

Do you have any references for this? Every print icon I've seen Apple use
looks like a printer, and every delete icon looks like a trash can. Is there
an article or something saying these caused confusion?

~~~
WalterBright
My reference is when an Apple salesman came by my workplace around the time
the Mac was released. He proudly showed off a sheet of icons, claiming they
were all obvious, to a group of maybe 15 of us. One pointed to an icon, and
said "what's that box of kleenex mean?" The salesman says "print, it looks
like a printer". We all laughed and said it looks like a box of kleenex. The
salesman didn't get much headway after that.

Printers come in all kinds of form factors. Besides, even if it was
recognizable as a printer, a printer is a _thing_ , not an _action_. Why
wouldn't it mean "configure the printer"?

~~~
Aeolun
You have to start somewhere. At this point if someone thought the printer icon
meant anything but ‘print’ I think they’d be very surprised.

~~~
WalterBright
It isn't any harder to learn what "print" means.

------
tadzik_
Nay, nay, nay.

I don't like text that looks differently for everyone depending on the
platform they're on.

Emojis have shown us already that vendors are willing to change their
appearance depending on current trends or political climate. Gun becomes water
gun, salad becomes vegan salad. One day, if caterpillar becomes a butterfly
because of some mundane idea, is it still going to be instantly recognizable
as a bug?

We write code in formal languages rather than natural ones to stay away from
ambiguity. Emojis are a straight downgrade.

~~~
chrisseaton
> I don't like text that looks differently for everyone depending on the
> platform they're on.

But we already have fonts that make the Latin alphabet look different on
different platforms.

> if caterpillar becomes a butterfly because of some mundane idea, is it still
> going to be instantly recognizable as a bug?

Yes? Didn’t Hopper tape a moth ‘bug’ into her notebook?

~~~
kps
> _But we already have fonts that make the Latin alphabet look different on
> different platforms._

But the differences in appearance are abstracted away; the whole point of an
alphabet is that it's a small fixed set of symbols. Conversely if you see 𓀪 on
one platform and 𓀫 on another, you have no idea whether the difference is
meaningful or decorative.

~~~
chrisseaton
> the whole point of an alphabet is that it's a small fixed set of symbols

Emoji _is_ an alphabet. There's a fixed set. I know they look different on
different platforms but it's the same Emoji. Just like how an A here looks
different to an A on Twitter. A vomiting face emoji conveys the same thing
however it's drawn.

~~~
kps
Emoji aren't a fixed set; there are new ones added all the time: 230 this
year, 157 last year, …. When I see an emoji, I can't tell whether it's an
existing one drawn in a different style, or whether it got added since the
last time I memorized the code chart.

------
danShumway
I've gotten into arguments over whether or not emoji belong in the unicode
standard at all, and I'm not going to rehash them here.

What I am going to say is that _regardless_ of whether or not emoji are a good
fit for unicode, they don't degrade gracefully for blind users (or for sighted
users on older hardware) and they're prone to rendering issues between
different fonts that can mask intent.[0]

Everything bad about icon fonts also applies to emoji. All of the articles
you've ever read about how svg icons are preferred[1] -- all of them apply to
emoji as well.

So in general, I only use unicode emoji[2] if two things are true

A) I'm in a closed conversation that won't be copied and pasted around or
shared publicly.

B) I know the exact platform that my reader will be using to view my text.

I don't think Git falls into either of those categories.[3]

[0]: [https://blog.emojipedia.org/apple-and-the-gun-
emoji/](https://blog.emojipedia.org/apple-and-the-gun-emoji/)

[1]: [https://cloudfour.com/thinks/seriously-dont-use-icon-
fonts/](https://cloudfour.com/thinks/seriously-dont-use-icon-fonts/)

[2]: I do _heavily_ use emoji shorthands (:bug: :cat_eating_avacodo:) but
these don't suffer from most of the same problems as emoji. They work as
progressive enhancements for the platforms that render them, and fall back to
readable text on the platforms that don't.

[3]: It's true that unicode fonts in general have issues when you get into
non-English languages, but I don't advise people to avoid, say, Chinese
characters, because: A) language glyphs don't change often enough to frighten
me on accessibility, B) people who need to see them are likely already using
devices that support their own languages, and C) we don't have a good
alternative we could use instead.

~~~
woodrowbarlow
> they don't degrade gracefully for blind users

why not? there is a canonical plain-text description for every unicode emoji.
at least in theory, i see no reason why a screen reader shouldn't be able to
handle emojis.

~~~
shakna
In theory, there's nothing stopping them.

But in reality, they don't work. They don't work today, and they probably
won't work next year. Heck, half of UTF-8 tends not to work.

Should a segment of the population that are forced to rely on poor tools (I
hate JAWS so very very much) be excluded today?

~~~
mwcampbell
> forced to rely on poor tools (I hate JAWS so very very much)

Blind Windows users aren't forced to use JAWS, at least in the sort of context
where they're likely to encounter emoji (i.e. I understand it may be forced in
some job settings). NVDA is freely available and Narrator is built in, and
both handle emoji well AFAIK.

Disclosure: I work at Microsoft on the Narrator team, but I'm just as happy if
you use NVDA.

~~~
shakna
> NVDA is freely available and Narrator is built in, and both handle emoji
> well AFAIK.

They may handle emoji, but they also regularly fail to handle other common
screen-reader situations well.

I do understand the difficulty - most interfaces today are visually-oriented,
and often don't include the necessary contexts for accessibility. This turns
our screenreader programs into massive and complex programs that have to
handle so many different formats and edge cases they become truly monolithic.

But I haven't found either of those to be up to a level of quality where I can
put up with them on a daily basis. JAWS is simply the least-worst at the
moment.

(Small examples: NVDA is similar to the sloths from Zootopia's DMV anytime
you're doing anything on a network (whether not its the active window).
Narrator's settings regularly get reset by updates, and will re-enable itself
at random and unexpected times).

~~~
mwcampbell
> NVDA is similar to the sloths from Zootopia's DMV anytime you're doing
> anything on a network

Do I understand this reference correctly? Are you saying NVDA is really slow
when you're doing anything on a network, even when that network activity is in
the background? Can you give an example? I've never experienced this nor heard
of it. But maybe I'm missing some specific detail of the Zootopia reference. I
watched that movie once, or rather listened to it without audio description
(with my family), and I don't remember the DMV scene that well.

> Narrator's settings regularly get reset by updates, and will re-enable
> itself at random and unexpected times).

Have you reported this through Feedback Hub? I haven't experienced or heard of
the problem with settings being reset by updates.

~~~
shakna
Yes, NVDA has some problems to do with network connectivity. It's a fairly
well-known problem. It has been solved several times, and re-appeared several
times, but getting the right trifecta of Windows version, network card and
NVDA version means it can take somewhere in the range of a full minute just to
say "Firefox".

\---

Windows isn't my daily driver, mostly because Windows 10 has at several points
reset _all_ the system settings with some updates, not just accessibility.
Again, this isn't an unknown problem. It may happen less often now the team
seems more aware of it, but it only has to happen once to render my computer
nearly useless. It's less of a problem with Narrator, and more the tightly
couple nature of Windows components and the decided drop in update quality in
recent years.

The part about Narrator randomly speaking is something has appeared since the
XP days. Now and then a single word will squeak through when the whole thing
is supposed to be on mute. It's completely unpredictable though, so I wouldn't
expect it (as a programmer) to be solved at any point soon.

------
letientai299
Definetely a no for me. I also hate seeing commit message littering with emoji
and feel like the author is too lazy to find correct words. I also disagree
with the "visual cue" advantage, because the emoji looks different per
machine/font/terminal/OS. Plain text looks consistent every where.

------
kfrzcode
> Forces you to make smaller and more specific commits

There's no forcing anyone to make smaller and specific commits. It may be used
as a reminder, or tool, but certainly not going to prevent someone from
committing junk behind whatever emoji they choose.

~~~
amarshall
Not to mention that a non-emoji based tagging scheme (e.g. “[bug]”, “[UI]”,
etc.) would likely have the same effect (if there is any) that the author
purports.

~~~
larusso
Plus the benefit of not being ambiguous like a lipstick emoji :)

~~~
josteink
I'd actually interpret that as "lipstick on a pig", or just "[hack]". I'm
honestly not sure what its intentions are.

Which I guess is one of the problems with this suggestion.

~~~
larusso
Depending on the screen I always see a Rotating police light in red at first.

------
johnisgood
Absolutely not. Keep your emojis out of my CLI and my face, even, as far as
professional areas of life are concerned. I see READMEs full of emojis, the
description of the project is full of emojis... I personally dislike it, and
it actually makes me reconsider digging more into that project. I might have
prejudices, but it is quite childish to me. The only place where I am fine
with emojis is instant messaging applications (for casual conversations). You
can even have stickers there if you want for all I care!

------
arkh
Nay.

> A picture says more than words

Because it relies on a lot of cultural background. Which in the world of emoji
changes fast. This won't be welcoming of new users when they have to learn 10
or more symbols for whatever you're doing.

:lipstick: for UI changes? Why? :computer: or :smartphone: as those are the
usual interface used or ️:wheelchair: because you care about something
accessible would feel better.

~~~
etiam
If we could have :pig: as well, we could at least do :lipstick::pig: for
kludges on bad code...

I think you're right on the mark about the strong cultural context and
arbitrariness of the symbols. The value I see in emoji for this sort of
application (as others have also pointed out here) is for jokes and maybe
(rarely) highlighting lines visually. Obviously the joke dies if the use gets
standardized, and the practical disadvantages far outweigh the advantages.

------
mondaygreens
Nay! Emoji is slang that excludes a huge number of people, not just due to
preference but also because the meaning keeps changing and can be confusing if
not exhausting to keep up with. It skews young and/or Western and there's far
more kinds of programmers than that.

~~~
kalleboo
> _It skews young and /or Western_

How does it skew Western when they were literally invented in Japan?

~~~
cattlefarmer
Yes, emoji is literally Japanese. 絵文字 meaning 'picture as words'. Invented for
use in Japanese pagers, later proliferating to mobile phones long before
smartphones even existed [0].

[0]:
[https://en.wikipedia.org/wiki/Emoji](https://en.wikipedia.org/wiki/Emoji)

------
mcs_
If we cannot describe in the subject what we are doing, we should not commit
it.

Icons are perfect to define actions (fixing bugs, improving the layout, etc)
however, the commit is important when you are doing releases, cherry-picks,
maintaining patches, etc.

I'm not against changes and sure the icons look very cool on the front page of
GitHub or in `git log`.

However, most of the maintainers, who actually do things with commits, they
work looking at the content. Be useful in the future, to understand what was
going on, is the main purpose of the commit message.

I agree that a bug, a rocket (and others) can be used to improve the subject
of a commit, eventually, the problems are:

-by introducing icons, are we creating a perfect excuse to be lazy during the commit phase?

-Will the icons makes our history of change the poorest?

------
jlillesand
I like it! I agree with many of the objections in other comments, but used
wisely emojis in commit messages can definitely add value.

1\. They add easy noticeable visual cues that might otherwise require reading
a full sentence (at that often will be omitted altogether).

2\. It's fun and informal, something that's often lacking in dev teams.

~~~
iainmerrick
It’s fun and informal until somebody tells you it’s mandatory.

~~~
jlillesand
Huh, that's a good point!

~~~
jlillesand
Also: HN strips emojis >:~(

~~~
iainmerrick
Informal fun is not allowed here!!

------
LockAndLol
That would require linux distros to distribute some kind of tool to display
them properly and enter them easily in the CLI as well as IDEs.

This is what it looks like to me:

\- [CLI]([http://i.imgur.com/XMcXwvi.png](http://i.imgur.com/XMcXwvi.png))

\- [Pycharm]([http://i.imgur.com/HOXj2yg.png](http://i.imgur.com/HOXj2yg.png))

Even displaying that recycle emoji required me to install some font from a
repo on github. Emojis seem to have very poor support on linux.

If [this
method]([http://i.imgur.com/v5eqgSJ.png](http://i.imgur.com/v5eqgSJ.png)) of
entry were standard then maybe it'd be interesting and I'd give it a try.

Given the current status of emoji support on linux, that's a big naw from me
dawg

~~~
have_faith
Apparently Ubuntu 18.04 introduced native emoji support through bundling
Google's Noto Colour emoji font and an emoji picker ui built into Gnome. Looks
very similar to MacOS's built in emoji picker that I'm used to.

~~~
LockAndLol
I am on 18.04, so it's not working if something was done.

------
lwhsiao
I'm also not a fan of emoji here. Though, I do like some systematic prefixes
for commits, such as the ones proposed by Conventional Commits:
[https://www.conventionalcommits.org/en/v1.0.0-beta.2/](https://www.conventionalcommits.org/en/v1.0.0-beta.2/)

------
t0astbread
I'd rather not but not because of the emoji but because atm I don't like
categorizing commits in the first place. I've just tried doing it on a project
and it felt pretty weird. Instead of just grouping single atomic changes like
I'd usually do, I suddenly also have to think about what category fits a
commit best and what to do if a commit satisfies multiple categories.

Thinking about it, emoji could actually help with this since it's easier to
assign multiple categories to a commit without wasting a lot of character
space. Still, what I'd rather want to see become a convention is an annotation
in the commit's body that simply marks whether it's a major/minor/patch bump
(or none). Plus optionally a line for the changelog. (Optionally because it
allows commits to stay small while also not cluttering the changelog.)

Any thoughts/feedback/etc on this?

------
wvh
> ... and last but not least it definitely adds joy and excitement .

Akin to the person with the boombox on public transport.

I could imagine wanting to highlight some keywords myself – for myself – but
now my screen has turned into a colourful shouting competition.

------
axegon
Absolutely not. Seriously if it comes to that, just add gifs and youtube
videos while you're at it.

------
majkinetor
I like this more then semantic git because:

\- same amount of chars to type

\- single char / img to read (way faster)

\- you can glance the commit log wall of text and still get a lot of info, not
something you can do with other forms

I don't like textual representation tho (i.e. :zap: vs :feature: ) and if u
watch log in systems that can't present images it might be actually harder to
understand

That would be general yay

------
xiconfjs
My main concern are blind people, I‘m not sure how well these emojis are
accessible for them.

~~~
amarshall
macOS VoiceOver reads one of the (but not necessarily the most useful in a
given context) names of the emoji. For example, gets read as “caterpillar”.
However, importantly: there’s no distinction that it’s an emoji when read.

Caveats: I have no idea what JAWS does here. I’m not a visually impaired user,
but have done a11y work in the past.

~~~
amarshall
Too late to edit now, but just realized HN scrubbed the emoji. “…For example,
<bug emoji used in OP> gets read…”

~~~
s_kilk
An object lesson in the problems of using emoji to actually convey meaning :)

~~~
scrollaway
It's a problem insofar as HN is, on purpose, stripping emoji. Which is a
questionable choice...

~~~
krageon
It saves people from having to guess which subculture you come from, just so
they can understand what a certain picture means for you. Emoji are very
irritating for this reason: They are focused on the writer, and not the
audience.

------
bbody
I have tried to use Gitmoji and other standards before on a few projects but I
have since stopped. The motivation behind it makes a lot of sense but I can
count the number of instances where I have used the emojis as a cue to find
problematic commits with one hand.

That being said, I never really thought about the point about forcing you to
ensure your commit is atomic. I definitely have become better at it but the
habit has stuck even after using Gitmoji.

------
aurbano
Off Topic question: What's up with all this .christmas blogs that I'm seeing
lately? New trend?

~~~
swebs
No, it's all from the same guy, and every post seems to get linked here.

------
bdeshi
Couldn't something text based ( like this[1] ) be standardized much easily?

1:
[https://gist.github.com/abravalheri/34aeb7b18d61392251a2](https://gist.github.com/abravalheri/34aeb7b18d61392251a2)

ed. I see another comment points to the conventionalcommits proposal.

------
bvda
I am glad I am not the only one against this. Especially iOS developers seem
to love to put Emoji in their tooling and git repos, but that's just my
experience.

------
sakisv
As long as there is a non-emoji description of what is happening in your
commit, use whatever you want. It's not something that I would ever use on
anything semi-serious but I'm not going to forbid people who want to express
themselves that way.

The one thing that _I will_ forbid them to do though is use it in branch names
- and especially in the beginning of the branch (if it's in the middle you can
use tab completion). Your commit is something that I can read or I can use its
hash, but branch names are something that I have to interact with directly and
I don't want to have to copy/paste the name from github or trying to figure
out how to type this emoji.

------
josteink
Nay. I'm clearly against this, and I don't find this kind of addition to the
git ecosystem productive.

And hopefully that won't translate into me being "hostile" towards women in
tech, just because this was proposed by a woman.

~~~
FroshKiller
It wouldn't have even occurred to me if you hadn't specifically mentioned it,
which now makes me suspect it does have something to do with the fact a woman
proposed it.

~~~
josteink
We have enough example of internet-outrage caused by tech-guys treating tech-
women as peers.

That is outrage over "hostility towards tech-women" when what is actually
happened was that guys criticized women equally as they would have criticized
men. Even seemingly respectable organizations like the Linux Foundations have
fallen prey to such nonsense fronted by (racist!) twitter lynch-mobs[1].

You'd think this be a pretty clear-cut case when considered objectively, but
it has proven controversial, even here on HN.

In such a climate, it is only reasonable to pro-actively guard against such
accusations. The troublesome part is that it's seemingly needed.

[1]
[https://twitter.com/hashtag/LinuxFoundationKangarooCourt](https://twitter.com/hashtag/LinuxFoundationKangarooCourt)

~~~
FroshKiller
That hashtag definitely does not change my mind.

------
golergka
As someone who had the pleasure to work with text rendering and wonders of
Unicode - hell no. I want my tools resilient, not fancy.

------
larusso
I had a short discussion about them just yesterday. It’s not a yay for me but
also not a nay. I use icons for change lists in pull requests and release
notes. But I use my own set of svg icons to have better control over the icons
themselves.

I don’t like these icons in commit message subject lines because they're too
ambiguous. If you adopt the imperative subject line style (Add class X, Fix
issue XYZ, etc.) you have all the same benefits plus a clearer meaning. Also
using a emoji plus a description like ‘:bug: fixes issue’ makes the whole
benefit of short one character icons go away.

------
rgoulter
Looking at
[https://gitmoji.carloscuesta.me/](https://gitmoji.carloscuesta.me/)

As the article says, I can see that the emojis align with the intended
meaning, but I'm pretty sure I'd not be able to guess the intended meaning
from the emoji of many of these.

I'd think prefixing a commit message with [linux] or [hotfix] or [refector]
provides the same at-a-glance benefit with less cognitive load when reading
the commits.

------
finger
Small note: it’s spelled ‘Yea’ and not ‘Yay’.

------
DivisionSol
I was about to go in fully to this style at most ~2 weeks ago.

It's another forcing function to be cognizant of what exactly you're working
on at a given time. (Speaking from JavaScript land,) don't update the
packages, fix two bugs, add a couple features, refactor some code all in the
same commit. When things go wrong in a few months, your bisect will land right
on that big blob of things. In the vein of focusing on things it's also nice
when reviewing code. Ideally reducing the amount of times someone sneaks in a
random 'bug fix' that eventually needs to be tracked down and added to the
spec.

Also, the idea of being able to categorize all commits into their respective
buckets between releases. A similar idea from the other commit message prepend
style out there, but with emojis. Grep for all :sparkles: and :bugs: and you
have your patch notes.

But, as I started with, I couldn't commit, (heh). Terminal + `zsh` on MacOS
Catalina seems to refuse to format emojis properly, often resulting in console
frustrations as spaces disappear and emojis overlap text. If anyone knows a
fix, let me know!

~~~
larusso
Instead of grep for :sparkles: etc you can also just grep for any other prefix
style. The biggest turn down for me is the fact that these emojis render
differently on each platform. It’s hard to transpose meaning for an icon that
is not static in its visual.

------
valryon
I’ve been consistently using it on my last 3 projects and I really like it. It
brings a simple visual clue to the content of a commit, it’s displayed
correctly on all my git clients, and it’s just fun. Also, you don’t want to
have more than one emoji so I agree it forces to have more atomic commits.

------
ww520
Nay. Non standard rendering is a problem.

------
todd3834
I recently started using emoji to name tmux windows and I find it pretty
useful. That being said this is probably pretty cool too. However, I could
never see myself enforcing such a thing in my flow. Let alone trying to
enforce it on others. It’s a nice thing if people want to do it though.

------
kaens
> A positive outcome of using gitmoji is the fact that it forces you to think
> through the content and message of your commits to a larger extent.

It really doesn't. My personal experience with people using them is that the
content and message of the commits is the same quality as they are without
them, but now they also have a pretty picture on the front of them.

It can _encourage_ people to think more about their commits but I can't say
I've seen a correlation.

I don't mind people wanting some "personality" in their commit one-liners, but
it's the message and not the icon that adds value.

------
martinbeentjes
It may be useful, but only if you implement it consistently in the workflow.
However, what will happen when someone new in the team comes along? I
personally prefer to prefix my commit message with the issue number if useful.

In the example given on their website (the PR example), it makes no sense to
me. It does not improve the quality of the titles. Did they remove animation,
did they add it? Replacing the emoji with 'add' or 'remove', the title
describes what happened inside that Pull Request.

Something does not have to be beautiful to be useful and readable.

------
sandGorgon
I think this is a highly regional preference even without meaning to be. Emoji
are more popular in Asia than in the Americas as part of normal conversation.

Probably because the entire generation of internet users right now _grew up_
on smartphones before laptops.

Secondly, we already struggle using international keyboards to find things
like rupee symbol (₹) vs the $, etc. Emojis are just next door to the effort.

------
t0astbread
Oh hey I just noticed this company has produced all of the recent "christmas"
posts and sites on HN. Thanks for that!

------
krzepah
I heard some ops willing them to have a clearer vision of what's commited but
I don't like being dependend on them. I ended up looking what kind of emoji I
had to use on every commit and it felt like a waste of my time

------
selbekk
We're considering it for our design system right now, but we're not sure how
well it'll work with conventional commits and commitizen.

~~~
iainmerrick
Are you sure you're not bikeshedding?

It sounds like you have several people discussing a change that's going to
have a limited impact on outcomes, if any at all. Another warning sign is if
people are having more fun arguing over the change than they would do actually
using the new system.

------
LeoNatan25
"Yay or Nay"?

Hell nay.

------
lovetocode
No

------
vaporland
coming soon: emojis completely replace ASCII text in source code.

------
cryptonector
No.

------
nathias
pls no

------
sergiotapia
Feels like a zoomer thing. I wouldn't do it for personal projects, and I
wouldn't allow it for teams I lead. They seem nice on the surface, but they
just become noise.

Ever install a popular node package? It barfs up a ton of emojis in my
terminal.

~~~
lvturner
Sorry, zoomer? Not familiar with that term

~~~
wizzwizz4
It's a way of segregating people by age, then acting derisively about various
groups in response to that. You identify bad character traits, call them out
with the relevant "generation" phrase, and then sneakily imply that they have
that character trait _because_ they're within that age range (even when
they're not).

~~~
feanaro
The worst part of it is that this obsession with "generations" is almost
exclusively tied to the US. In most countries, this concept is not part of the
memescape at all, so it's even more confusing.

~~~
bonoboTP
When you think about it a bit, you realize there just cannot be "generations"
in that sense. People are continuously being born in each and every year. In a
family tree there are generations sure, based on the levels of the tree, but
not in a population.

The exception is special baby boom periods and their echoes, which do create
some more "lumping" or births.

The worst is when people try to apply American generational stereotypes to
other countries. Like, no, Hungarian "boomers" didn't grow up in plenty. The
50s were a period of terror and deprivation, not the "good ole days" of
prosperity.

~~~
wizzwizz4
Coming from a culture without this obsession, it took me a very long time to
_learn_ the concept of generations. And I'm quite upset that I did; it's
fairly deeply embedded in my mind, now, as I tied it to so many other concepts
in a desperate attempt to make it make any sense. (Is a generation twenty
years, or fifty? I still don't know.) It takes some effort to make that
realisation now, but I remember thinking exactly those arguments when I was
younger, trying to reject the concept.

~~~
bonoboTP
> Is a generation twenty years, or fifty? I still don't know

Should be the same as the age gap between parents and children, so about 20-40
years, roughly speaking.

