6 ms·

Atom – Git commit messages

86 points by selvan 12y ago

mrcwinn 12y ago
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.
- Navarr 12y ago
  Well, this is specifically for contributing to Atom - and if you look at their commit messages it looks like they're at least somewhat doing just that.
- cocoflunchy 12y ago
  They are using it though: https://github.com/atom/atom/commit/f151697c4cd0c22cfac9ab19b529691724148a9c https://github.com/atom/atom/commit/f151697c4cd0c22cfac9ab19... https://github.com/atom/atom/commit/f151697c4cd0c22cfac9ab19b529691724148a9c https://github.com/atom/atom/commit/f151697c4cd0c22cfac9ab19... https://github.com/atom/atom/commit/325d95ed35bb3f1a1741e77de984113fdea12595 https://github.com/atom/atom/commit/325d95ed35bb3f1a1741e77d... https://github.com/atom/atom/commit/a606fc516b19ee87530168356456116e4e6b7335 https://github.com/atom/atom/commit/a606fc516b19ee8753016835...
- leejo 12y ago
  > 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...
  - igorgue 12y ago
    Well, if you read their guide it says that :lipstick: means: "improving the format/structure of the code" So I guess this code just changes spaces or something like that, I don't know I'm just reading what they do, they might do something else, I'm just following the instructions that everyone contributing to the code should.
    - leejo 12y ago
      OK, the guidelines explain the meaning but the message is still not descriptive enough. What happens when one of those commits breaks something? If i ran a bisect and the offending commit had the message: :lipstick: I would be tempted to revert the commit because the message tells me nothing about why the change was made. A commit message should be future proofed, even if the code it relates to can never be.
  - bradleybuda 12y ago
    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-changing-source-formatting http://stackoverflow.com/questions/2214480/committing-when-c...
    - leejo 12y ago
      > 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.
tw04 12y ago
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.
- deleted 12y ago
  [deleted]
- andyhmltn 12y ago
  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.
krat0sprakhar 12y ago
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.
- diggan 12y ago
  Because generally you're reading commits that happened before and you want to know what happens when you apply the commit. It goes something like this. "Hmm, I wonder what would happen if I merge 1231knf?" It would "Add email integration on /email route" Otherwise it would be something like "What happens when I merge this commit?" "Added email integration on /email route" It's considered as best practice when using Git to write in present tense.
  - nirvdrum 12y ago
    That's one interpretation. Another is you're looking at git log and it's all historical. The best practice bit seems to boil down to "because Linus said so." The rest of the git commit best practices seem to fall into a similar boat. I'm of the mindset a team can be mature enough to pick what works best for them. If the idea of a commit message is to convey useful info, imposing hard rules like 72 chars or tense seems a bit draconian. The worst change GitHub has made IMHO is truncating messages (particularly because the truncated message often ends up longer).
    - jamesn 12y ago
      The reason for the 72 character limit is so that shortlog messages on an 80 character terminal which are indented by one tab aren't truncated, as I understand it.
      - nirvdrum 12y ago
        I get that. And in certain scenarios where even pagers aren't available require that. But I'd expect that team to handle it, not for it to be a general purpose rule. In contrast, a Nokia postage stamp feature phone can display a message more than twice as long (SMS - 160 chars). Limiting to 72 chars across the board seems to be more dogmatic than anything else from my POV.
raju 12y ago
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-commit-msg.js#L21-31 https://github.com/angular/angular.js/blob/master/validate-c... The format they enforce is here - https://github.com/angular/angular.js/blob/master/validate-commit-msg.js#L58 https://github.com/angular/angular.js/blob/master/validate-c... 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.
bhhaskin 12y ago
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.
davexunit 12y ago
>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.
- eterm 12y ago
  It's their project, if you want to contribute why not follow their guidelines? The emojii are just shorthands for [CodeImprovement], [Feature], or whatever you might otherwise tag commits as.
- k2xl 12y ago
  "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 12y ago
    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 12y ago
      These are small and coloured, so they're easy to see in a list.
      - Morgawr 12y ago
        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.
rplnt 12y ago
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 12y ago
  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 12y ago
    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.
potomak 12y ago
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-messages https://github.com/erlang/otp/wiki/Writing-good-commit-messa...
unhammer 12y ago
They contradict themselves. Should it be present ("Is/are less buggy") or imperative ("Be less buggy")?
- Artemis2 12y ago
  Imperative present. These are compatible. Writing a commit also implies the use of verbs related to actions.
kmfrk 12y ago
The lipstick one seems pretty silly - especially if one is familiar with the idiom "lipstick on a pig".
AdmiralAsshat 12y ago
Do Android-centered commits use the Linux emoji, or should we be lobbying for a mobile-device emoji?
re1ser 12y ago
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.

86 points by selvan 12y ago

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.

Navarr 12y ago
Well, this is specifically for contributing to Atom - and if you look at their commit messages it looks like they're at least somewhat doing just that.
cocoflunchy 12y ago
They are using it though: https://github.com/atom/atom/commit/f151697c4cd0c22cfac9ab19b529691724148a9c https://github.com/atom/atom/commit/f151697c4cd0c22cfac9ab19... https://github.com/atom/atom/commit/f151697c4cd0c22cfac9ab19b529691724148a9c https://github.com/atom/atom/commit/f151697c4cd0c22cfac9ab19... https://github.com/atom/atom/commit/325d95ed35bb3f1a1741e77de984113fdea12595 https://github.com/atom/atom/commit/325d95ed35bb3f1a1741e77d... https://github.com/atom/atom/commit/a606fc516b19ee87530168356456116e4e6b7335 https://github.com/atom/atom/commit/a606fc516b19ee8753016835...
leejo 12y ago
> 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...
- igorgue 12y ago
  Well, if you read their guide it says that :lipstick: means: "improving the format/structure of the code" So I guess this code just changes spaces or something like that, I don't know I'm just reading what they do, they might do something else, I'm just following the instructions that everyone contributing to the code should.
  - leejo 12y ago
    OK, the guidelines explain the meaning but the message is still not descriptive enough. What happens when one of those commits breaks something? If i ran a bisect and the offending commit had the message: :lipstick: I would be tempted to revert the commit because the message tells me nothing about why the change was made. A commit message should be future proofed, even if the code it relates to can never be.
- bradleybuda 12y ago
  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-changing-source-formatting http://stackoverflow.com/questions/2214480/committing-when-c...
  - leejo 12y ago
    > 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.

tw04 12y ago

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.

deleted 12y ago
[deleted]
andyhmltn 12y ago
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.

krat0sprakhar 12y ago

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.

diggan 12y ago
Because generally you're reading commits that happened before and you want to know what happens when you apply the commit. It goes something like this. "Hmm, I wonder what would happen if I merge 1231knf?" It would "Add email integration on /email route" Otherwise it would be something like "What happens when I merge this commit?" "Added email integration on /email route" It's considered as best practice when using Git to write in present tense.
- nirvdrum 12y ago
  That's one interpretation. Another is you're looking at git log and it's all historical. The best practice bit seems to boil down to "because Linus said so." The rest of the git commit best practices seem to fall into a similar boat. I'm of the mindset a team can be mature enough to pick what works best for them. If the idea of a commit message is to convey useful info, imposing hard rules like 72 chars or tense seems a bit draconian. The worst change GitHub has made IMHO is truncating messages (particularly because the truncated message often ends up longer).
  - jamesn 12y ago
    The reason for the 72 character limit is so that shortlog messages on an 80 character terminal which are indented by one tab aren't truncated, as I understand it.
    - nirvdrum 12y ago
      I get that. And in certain scenarios where even pagers aren't available require that. But I'd expect that team to handle it, not for it to be a general purpose rule. In contrast, a Nokia postage stamp feature phone can display a message more than twice as long (SMS - 160 chars). Limiting to 72 chars across the board seems to be more dogmatic than anything else from my POV.

raju 12y ago

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-commit-msg.js#L21-31 https://github.com/angular/angular.js/blob/master/validate-c... The format they enforce is here - https://github.com/angular/angular.js/blob/master/validate-commit-msg.js#L58 https://github.com/angular/angular.js/blob/master/validate-c... 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.

bhhaskin 12y ago

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.

davexunit 12y ago

>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.

eterm 12y ago
It's their project, if you want to contribute why not follow their guidelines? The emojii are just shorthands for [CodeImprovement], [Feature], or whatever you might otherwise tag commits as.
k2xl 12y ago
"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 12y ago
  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 12y ago
    These are small and coloured, so they're easy to see in a list.
    - Morgawr 12y ago
      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.

rplnt 12y ago

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 12y ago
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 12y ago
  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.

potomak 12y ago

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-messages https://github.com/erlang/otp/wiki/Writing-good-commit-messa...

unhammer 12y ago

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

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

kmfrk 12y ago

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

AdmiralAsshat 12y ago

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

re1ser 12y ago

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.