4 ms·

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 wei

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.
      - giovannibajo1 12y ago
        I think that the boat already sailed, there are many tools that assume that shortlogs are 72, and can be displayed on a single line, and format accordingly, including GitHub for instance. Besides, whether it's 72 or 100, it makes sense to force people to have a concise summary.
        nirvdrum 12y ago
        GitHub's approach is one reason I've started using BitBucket more. GitHub didn't always used to do this. I've assumed they started so they could have fixed height commit displays in their commit list. It seems weird to force this on people otherwise.
bsimpson 12y ago
Angular has similar rules. 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."
raju 12y ago
I believe the motivation is explained here - http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa... 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.
- philh 12y ago
  That mostly just passes the buck to why do merge and revert use the imperative? Simply being consistent with them doesn't seem like a very strong argument.
vertex-four 12y ago
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. [0] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=HEAD#n133 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
icefox 12y ago
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
- Morgawr 12y ago
  I see three different types of commits in my codebase, usually. * The big fix: This is the commit which usually is too complex to be explained in a 72-characters message. Usually it refers to an issue number on the project's issue tracker, which in my case is Github. * The medium fix: This is a commit whose "why" fits properly into 72 characters, i.e. "Add classes to validate user input only on Friday". * The small/obvious fix: This is a very small commit, usually fixes obvious issues like CI builds, misspellings in doc files, missing semi-colons, etc etc. In the last case, I find it appropriate to write the "how" rather than the "why" in the commit message, since the why is already obvious. i.e. "Add missing comma on object identifier".
- davexunit 12y ago
  >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=fb519bd8313e192d6eca2e51f9f33c87e5ee883e http://git.savannah.gnu.org/cgit/guix.git/commit/?id=fb519bd...
  - qznc 12y ago
    Comments tell why the code does what it does. Commit messages tell why the code does something different than before. Example comment: i++; // because server starts counting at 0 (not 1) Example commit: Our customer switched to bar (from foo), which starts counting at 0 instead
Igglyboo 12y ago
Say you want to apply a certain commit to your branch, it makes more sense to "add" a feature than to "added" a feature. What does a commit do? It adds/fixes/breaks, it doesn't added/fixed/broke.
- krat0sprakhar 12y ago
  Thats one way of looking at it. Another way is - What did I(the developer) do in the commit? I added/fixed/broke, right?
mponw 12y ago
"/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.
kasbah 12y ago
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.
Artemis2 12y ago
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...".

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.
    - giovannibajo1 12y ago
      I think that the boat already sailed, there are many tools that assume that shortlogs are 72, and can be displayed on a single line, and format accordingly, including GitHub for instance. Besides, whether it's 72 or 100, it makes sense to force people to have a concise summary.
      - nirvdrum 12y ago
        GitHub's approach is one reason I've started using BitBucket more. GitHub didn't always used to do this. I've assumed they started so they could have fixed height commit displays in their commit list. It seems weird to force this on people otherwise.

bsimpson 12y ago

Angular has similar rules. 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."

raju 12y ago

I believe the motivation is explained here - http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa... 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.

philh 12y ago
That mostly just passes the buck to why do merge and revert use the imperative? Simply being consistent with them doesn't seem like a very strong argument.

vertex-four 12y ago

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. [0] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=HEAD#n133 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...

icefox 12y ago

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

Morgawr 12y ago
I see three different types of commits in my codebase, usually. * The big fix: This is the commit which usually is too complex to be explained in a 72-characters message. Usually it refers to an issue number on the project's issue tracker, which in my case is Github. * The medium fix: This is a commit whose "why" fits properly into 72 characters, i.e. "Add classes to validate user input only on Friday". * The small/obvious fix: This is a very small commit, usually fixes obvious issues like CI builds, misspellings in doc files, missing semi-colons, etc etc. In the last case, I find it appropriate to write the "how" rather than the "why" in the commit message, since the why is already obvious. i.e. "Add missing comma on object identifier".
davexunit 12y ago
>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=fb519bd8313e192d6eca2e51f9f33c87e5ee883e http://git.savannah.gnu.org/cgit/guix.git/commit/?id=fb519bd...
- qznc 12y ago
  Comments tell why the code does what it does. Commit messages tell why the code does something different than before. Example comment: i++; // because server starts counting at 0 (not 1) Example commit: Our customer switched to bar (from foo), which starts counting at 0 instead

Igglyboo 12y ago

Say you want to apply a certain commit to your branch, it makes more sense to "add" a feature than to "added" a feature. What does a commit do? It adds/fixes/breaks, it doesn't added/fixed/broke.

krat0sprakhar 12y ago
Thats one way of looking at it. Another way is - What did I(the developer) do in the commit? I added/fixed/broke, right?

mponw 12y ago

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

kasbah 12y ago

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.

Artemis2 12y ago

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