

Atom – Git commit messages - selvan
https://atom.io/docs/latest/contributing#git-commit-messages

======
krat0sprakhar
Cool fun idea - I dont understand though whats the reasoning behind using the
present tense.

$ git commit -m "Add email integration on /email route" sounds weird for an
activity _that has been_ completed.

~~~
icefox
I thought it was very meta amusing that the author was trying to tell users
how to write commit messages when the number one rule of commit messages in my
book is explaining WHY the commit exists. Why does this patch change this or
do that. So it was amusing when he lists commit rules without explaining why
they are rules. But I was saddened when I got to the end and missing from the
list is 'explain why'.

Why did you 'Add feature...'? Why did you 'Move cursor to...'?

I did stuff // Increment i by 1

Why I did stuff // Increment i by 1 to not have a off by 1 bug

~~~
davexunit
>the number one rule of commit messages in my book is explaining WHY the
commit exists

The commit message should say _what_ changed, not why. Comments are for
explaining why the code does what it does.

Good commit log:
[http://git.savannah.gnu.org/cgit/guix.git/commit/?id=fb519bd...](http://git.savannah.gnu.org/cgit/guix.git/commit/?id=fb519bd8313e192d6eca2e51f9f33c87e5ee883e)

~~~
pjc50
The diff shows you what changed. The commit message is a comment on the diff
and absolutely should say what it's for.

This enables you to easily compile release notes, for example.

~~~
davexunit
Yes, it should say what it's for, but it shouldn't need to explain itself any
further. Sorry if I didn't make that clear. For example, if someone refactored
something, the commit log can simply say "Factorize foo", it need not explain
_why_ they were refactoring in the first place.

------
mrcwinn
I'm sure this isn't real or just a fun joke. Please don't consider using a
:checkered_flag: emoji to indicate you are fixing something on Windows, or any
of these other icons.

Or:

Please consider using these emoji, but please don't anticipate or expect other
developers will have any idea what their usage means.

~~~
leejo
> Please consider using these emoji

Fine with that, but please also write longer descriptive commit messages. For
example:

    
    
      > git log -1 3b5bb1501ce7af8f857af7621fc0d5f86fb4fa93
    
      commit 3b5bb1501ce7af8f857af7621fc0d5f86fb4fa93
      Author: Ben Ogle <ogle.ben@gmail.com>
      Date:   Tue Jan 6 17:09:59 2015 -0800
    
         :lipstick:
    
    

Tells me nothing. Nothing! At a glance the commit messages for the atom repo
are poor:

    
    
      atom > git-mean-commit-message-bytes | grep '>'
      >ALL 147
    

You would hope github and git users would grok the power of git's commit
messages, but hey ho...

~~~
bradleybuda
I'm guessing that's intentional. The idea is that if you are going to reformat
code, it should be the _only_ thing you do in a change; in other words, don't
commit a change that both changes the semantics of the code and changes the
formatting.

The principle is that formatting is orthogonal to other work and therefore
shouldn't be mixed in. Unless you do something wrong, formatting changes are
harmless so they can be scanned past by someone reviewing a changelog.

Here's a good discussion of the practice on StackOverflow:
[http://stackoverflow.com/questions/2214480/committing-
when-c...](http://stackoverflow.com/questions/2214480/committing-when-
changing-source-formatting)

~~~
leejo
> Unless you do something wrong

Therein lies the rub; when something goes wrong i want a commit message that
explains _why_ that formatting change was made.

    
    
      :lipstick: - add missing # char, as per conventions
    

Would have taken all of 5 extra seconds to write and is a lot better future
proofed. Remember, a commit message should explain _why_ something changed and
not just _what_ changed.

------
rplnt
Are those emoji an attempt at vendor lock-in? Want to contribute to our
project? Use our version of git. I hope this doesn't spread elsewhere.

I'd accept showing icons when certain commit/commit message criteria are met,
for example "refactoring" in commit message or perhaps whitespace commit would
trigger the lipstick icon. But putting :lipstick: as the first word in your
commit message? What user davexunit said.

~~~
laurent123456
Aren't these standard? There's the beer icon showing up when using Homebrew on
OSX, I guess the other ones would show up too on a `git log`.

~~~
rspeer
The Unicode characters are standard.

However, encoding them as ASCII strings such as ":lipstick:" is not, and that
ASCII string is what goes into the commit message. git will not decode these
messages as the emoji characters, as far as I know, and I expect that Linus
Torvalds would have some choice words if that were a feature request.

Sequences such as ":lipstick:" are a hack to work around the fact that PCs (as
opposed to phones and tablets) are bad at both inputting and displaying emoji.

------
raju
I came across the "tags" that the AngularJS uses, and have found these to be a
lot more relevant to my projects. I agree with @mrcwinn that expecting other
developers to understand the usage of some of these is asking too much
(`:lipstick:` ??? ).

[https://github.com/angular/angular.js/blob/master/validate-c...](https://github.com/angular/angular.js/blob/master/validate-
commit-msg.js#L21-31)

The format they enforce is here -
[https://github.com/angular/angular.js/blob/master/validate-c...](https://github.com/angular/angular.js/blob/master/validate-
commit-msg.js#L58)

If done right then these tags can be invaluable when using tools like `git-
bisect` - you can safely ignore the ones marked `docs` or `style` (assuming
you are not working with a language like Python).

Not to mention you can build automation around like, for e.g. automatically
generating release notes.

------
kmfrk
The lipstick one seems pretty silly - especially if one is familiar with the
idiom "lipstick on a pig".

------
unhammer
They contradict themselves. Should it be present ("Is/are less buggy") or
imperative ("Be less buggy")?

~~~
Artemis2
Imperative present. These are compatible. Writing a commit also implies the
use of verbs related to actions.

------
potomak
The best git commit message style guide in my opinion is Erlang OTP's "Writing
good commit messages"[0] wiki page.

[0] [https://github.com/erlang/otp/wiki/Writing-good-commit-
messa...](https://github.com/erlang/otp/wiki/Writing-good-commit-messages)

------
bhhaskin
I have been using atom sense its initial beta release and it has come quite a
long way. Some of these contribution guidelines might seem silly (such as the
emoji) but it definitely works for the community.

------
re1ser
Did they improved startup time of the editor? Last time I tested it (Windows 7
x64bit) it took good 3-5 seconds for it to start.

------
AdmiralAsshat
Do Android-centered commits use the Linux emoji, or should we be lobbying for
a mobile-device emoji?

------
davexunit
>Use the present tense ("Add feature" not "Added feature")

Agreed.

>Use the imperative mood ("Move cursor to..." not "Moves cursor to...")

Agreed.

>Limit the first line to 72 characters or less

Agreed.

>Reference issues and pull requests liberally

Agreed.

>Consider starting the commit message with an applicable emoji

Fuck off. This is completely useless and doesn't deserve 14 examples when the
above sensible directions are so brief.

~~~
k2xl
"Fuck off" \- seriously? Why use such inflammatory language in your post. A
simple "Disagree" would have sufficed.

IMHO the tags are a quick way to filter commits by each of those. The images
are just for quicker reference.

~~~
Morgawr
How is "lipstick" and "checkered flag" a more appropriate tag than a more
specific, less ambiguous and more concise technical word?

Most projects already use tags like "FIX" "CHANGE" "NEW" etc etc, there really
is no reason to use ambiguous emojis.

~~~
shawnz
These are small and coloured, so they're easy to see in a list.

~~~
Morgawr
They are definitely not small and coloured on my terminal screen. Maybe we
should update git or github with proper tracking and tagging (wait, git
already supports tags! But that's for a different thing anyway) instead of
using something that was not intended for this purpose. Especially because, as
I said, it's ambiguous and it really doesn't bring any benefit on the table.

------
tw04
So... emoji, but still horrible performance? Moving on...

Really? Downvotes without a response? Seems awfully cowardly. So I'll just
assume the performance has improved to the point that opening a large file
doesn't cause it to lockup for an hour? Because that seems a lot more
important to me than emoji's for commits...

*nope, just tried it again, performance still blows.

~~~
andyhmltn
The downvotes were (I assume) because you are going completely off-topic. This
isn't about performance of the Atom application, it's about their commit
guidelines for contributing to the project.

Editing your comments to attack people that downvoted you is only going to
make the situation worse. Just face the fact that it probably wasn't a good
comment and move on.

