Hacker News Reader

Comment by Xcelerate | Hacker News Reader

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

View on HN

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

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.

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.

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.

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.

There are much better tools to manage TODOs and bugs. Not to mention the visibility of commit messages outside of the dev team.

I think I would write "Fixes bug foo".

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

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

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

You could make that argument, but I would lean towards consitency. (For example, git uses "Merge ..." for merge commits" as opposed to "Merged ...")

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

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

Reply on news.ycombinator.com