3 ms·

The imperative form makes no sense. You're not commanding that something should be done -- you're telling what you have done. Unless there's a compelling reas

The imperative form makes no sense. You're not commanding that something should be done -- you're telling what you have done. Unless there's a compelling reason to violate the typical rules of grammar, I will stick with past tense (or alternatively "fixes", "updates", etc.)

michaelmior 14y ago
Git uses the imperative for a lot of its output, so this makes perfect sense to me.
- dmlorenzetti 14y ago
  One could equally well argue against using imperative, then: "Git uses imperative, so by avoiding it, you make clear which messages were human-written, and which were auto-generated."
- michaelmior 14y ago
  You could make that argument, but I would lean towards consitency. (For example, git uses "Merge ..." for merge commits" as opposed to "Merged ...")
benblodgett 14y ago
I agree, this post seems nonsensical to me - I always use past tense because it is a description of what I did.
- drstewart 14y ago
  However, the commit message should describe what the commit does, not what you did. What happens if I apply commit X to my project? Will it "Fix bug 35035" or "Fixed bug 35035"?
Karunamon 14y ago
Came to say exactly this. If I see a commit message along the lines of : Fix bug foo I'm going to assume that there is a bug that exists in this release that the author intends to fix later. Kind of like a TODO, which is what it sounds like.
- activepeanut 14y ago
  There are much better tools to manage TODOs and bugs. Not to mention the visibility of commit messages outside of the dev team.
- highwind 14y ago
  I think I would write "Fixes bug foo".
jpalomaki 14y ago
I think the imperative form feels better in release notes. A random example from Chromium project[1]. There you can compare to get a feeling, because they are using both forms. [1] http://www.chromium.org/getting-involved/dev-channel/release-notes http://www.chromium.org/getting-involved/dev-channel/release...
4ad 14y ago
Imperative form is recommended in Git documentation itself and it's what the Linux kernel uses[1]. It makes a lot of sense if you don't view DVCSes as a fancy history mechanism but as a patch management system. Here, take this bunch of patches. What will I do if I'll merge them? I'll fix X, add option Z and port Q to ARM. Now let's say I also want to backport some patches to a stable branch, I'll take one from this branch, some from others and I'll fix X, fix Y and fix Z, but on ARM nothing works without the ARM commit, so on that branch I'll port Q to ARM. [1] http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatches;h=ece3c77482b3ff006b973f1ed90b708e26556862;hb=HEAD#l12 http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/...
- pattern 14y ago
  Thank you for that link, I'm glad to have that data point in my head now. At first I misread your explanation of DVCS as a patch management system and was going to say that non-imperative forms of commit summaries would function similarly. Now I understand your point, and I thank you again for explaining a useful way to conceptualize what merging multiple git commits together actually accomplishes.
foldr 14y ago
I think the "imperative" here is actually better understood as the bare infinitive. (Of course, the two are morphologically identical in English, so you can't see the difference.) My guess is that in a language with a morphologically distinct imperative form, it would sound downright weird to put the commit message in the imperative, but it would sound fine to use the infinitive. For example, Spanish has a distinct imperative, but I've noticed that signs, instructions on shampoo bottles, etc., generally use the infinitive.
- bgilroy26 14y ago
  While I agree with your analysis, an alternative view is that a commit message in the imperative form would pair well with the code fix. With a bit of revisionism it reads like a wizard's incantation: fix bug! ::code that fixes bug:: add feature! ::code that adds feature:: add documentation! ::comments etc.:: After all, in an ideal world, every code change would simply be the execution of the whiteboard/pencil-and-paper/planning that precedes it.

michaelmior 14y ago

Git uses the imperative for a lot of its output, so this makes perfect sense to me.

dmlorenzetti 14y ago
One could equally well argue against using imperative, then: "Git uses imperative, so by avoiding it, you make clear which messages were human-written, and which were auto-generated."
michaelmior 14y ago
You could make that argument, but I would lean towards consitency. (For example, git uses "Merge ..." for merge commits" as opposed to "Merged ...")

benblodgett 14y ago

I agree, this post seems nonsensical to me - I always use past tense because it is a description of what I did.

drstewart 14y ago
However, the commit message should describe what the commit does, not what you did. What happens if I apply commit X to my project? Will it "Fix bug 35035" or "Fixed bug 35035"?

Karunamon 14y ago

Came to say exactly this. If I see a commit message along the lines of : Fix bug foo I'm going to assume that there is a bug that exists in this release that the author intends to fix later. Kind of like a TODO, which is what it sounds like.

activepeanut 14y ago
There are much better tools to manage TODOs and bugs. Not to mention the visibility of commit messages outside of the dev team.
highwind 14y ago
I think I would write "Fixes bug foo".

jpalomaki 14y ago

I think the imperative form feels better in release notes. A random example from Chromium project[1]. There you can compare to get a feeling, because they are using both forms. [1] http://www.chromium.org/getting-involved/dev-channel/release-notes http://www.chromium.org/getting-involved/dev-channel/release...

4ad 14y ago

Imperative form is recommended in Git documentation itself and it's what the Linux kernel uses[1]. It makes a lot of sense if you don't view DVCSes as a fancy history mechanism but as a patch management system. Here, take this bunch of patches. What will I do if I'll merge them? I'll fix X, add option Z and port Q to ARM. Now let's say I also want to backport some patches to a stable branch, I'll take one from this branch, some from others and I'll fix X, fix Y and fix Z, but on ARM nothing works without the ARM commit, so on that branch I'll port Q to ARM. [1] http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/SubmittingPatches;h=ece3c77482b3ff006b973f1ed90b708e26556862;hb=HEAD#l12 http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/...

pattern 14y ago
Thank you for that link, I'm glad to have that data point in my head now. At first I misread your explanation of DVCS as a patch management system and was going to say that non-imperative forms of commit summaries would function similarly. Now I understand your point, and I thank you again for explaining a useful way to conceptualize what merging multiple git commits together actually accomplishes.

foldr 14y ago

I think the "imperative" here is actually better understood as the bare infinitive. (Of course, the two are morphologically identical in English, so you can't see the difference.) My guess is that in a language with a morphologically distinct imperative form, it would sound downright weird to put the commit message in the imperative, but it would sound fine to use the infinitive. For example, Spanish has a distinct imperative, but I've noticed that signs, instructions on shampoo bottles, etc., generally use the infinitive.

bgilroy26 14y ago
While I agree with your analysis, an alternative view is that a commit message in the imperative form would pair well with the code fix. With a bit of revisionism it reads like a wizard's incantation: fix bug! ::code that fixes bug:: add feature! ::code that adds feature:: add documentation! ::comments etc.:: After all, in an ideal world, every code change would simply be the execution of the whiteboard/pencil-and-paper/planning that precedes it.