It's a standard to use the imperative mood in writing commit messages - the Linux kernel enforces this[0], as do a lot of other projects.
It makes more sense if you consider a commit to be an independent "thing" in a list, and you follow the list from start to finish to end up with the current repository state, each commit being a command.
Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." This convention matches up with commit messages generated by commands like git merge and git revert.
I tend to use that style because it matches git's generated commits ("Merge ...") and it saves a few characters. I found that when using a different tense ("Adding" or "Added") I would run out of characters more often.
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
Maybe it's because "Add" is shorter than "Adding" or "Added"? When I first worked on a project that followed the Angular pattern, the guy ramping me up said "Just imagine that you're commanding the computer to do something, and use that tense."
The past sounds good, until recently I was writing my commit messages using it, but when you start making pull requests on GitHub, you realize that it makes a lot more sense in general to use present for the titles of your commits.
A commit can be seen as a patch, which has a single purpose: "Add...".
"/email route: Email integration added" is my favorite way. Same thing with code naming, I always put the widest context first, then narrow down. With this habit I spend a lot less time thinking about names.
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.
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.
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.
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:` ??? ).
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.
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.
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.
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|11 years ago|reply
$ git commit -m "Add email integration on /email route" sounds weird for an activity that has been completed.
[+] [-] vertex-four|11 years ago|reply
It makes more sense if you consider a commit to be an independent "thing" in a list, and you follow the list from start to finish to end up with the current repository state, each commit being a command.
[0] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
[+] [-] diggan|11 years ago|reply
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.
[+] [-] raju|11 years ago|reply
Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." This convention matches up with commit messages generated by commands like git merge and git revert.
[+] [-] kasbah|11 years ago|reply
[+] [-] icefox|11 years ago|reply
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
[+] [-] bsimpson|11 years ago|reply
Maybe it's because "Add" is shorter than "Adding" or "Added"? When I first worked on a project that followed the Angular pattern, the guy ramping me up said "Just imagine that you're commanding the computer to do something, and use that tense."
[+] [-] Artemis2|11 years ago|reply
A commit can be seen as a patch, which has a single purpose: "Add...".
[+] [-] mponw|11 years ago|reply
[+] [-] Igglyboo|11 years ago|reply
What does a commit do? It adds/fixes/breaks, it doesn't added/fixed/broke.
[+] [-] mrcwinn|11 years ago|reply
Or:
Please consider using these emoji, but please don't anticipate or expect other developers will have any idea what their usage means.
[+] [-] cocoflunchy|11 years ago|reply
https://github.com/atom/atom/commit/f151697c4cd0c22cfac9ab19...
https://github.com/atom/atom/commit/f151697c4cd0c22cfac9ab19...
https://github.com/atom/atom/commit/325d95ed35bb3f1a1741e77d...
https://github.com/atom/atom/commit/a606fc516b19ee8753016835...
[+] [-] Navarr|11 years ago|reply
[+] [-] leejo|11 years ago|reply
Fine with that, but please also write longer descriptive commit messages. For example:
Tells me nothing. Nothing! At a glance the commit messages for the atom repo are poor: You would hope github and git users would grok the power of git's commit messages, but hey ho...[+] [-] rplnt|11 years ago|reply
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|11 years ago|reply
[+] [-] raju|11 years ago|reply
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-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.
[+] [-] kmfrk|11 years ago|reply
[+] [-] unhammer|11 years ago|reply
[+] [-] Artemis2|11 years ago|reply
[+] [-] potomak|11 years ago|reply
[0] https://github.com/erlang/otp/wiki/Writing-good-commit-messa...
[+] [-] bhhaskin|11 years ago|reply
[+] [-] re1ser|11 years ago|reply
[+] [-] AdmiralAsshat|11 years ago|reply
[+] [-] davexunit|11 years ago|reply
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|11 years ago|reply
IMHO the tags are a quick way to filter commits by each of those. The images are just for quicker reference.
[+] [-] eterm|11 years ago|reply
The emojii are just shorthands for [CodeImprovement], [Feature], or whatever you might otherwise tag commits as.
[+] [-] tw04|11 years ago|reply
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|11 years ago|reply
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.
[+] [-] unknown|11 years ago|reply
[deleted]