106

So which is it that you think is better and more intuitive?

Fixed the XXX bug in YYY
Fix the XXX bug in YYY
Fixes the XXX bug in YYY
Fixing the XXX bug in YYY

Please provide your rationales. Note I am asking from your general perspective, meaning you should not try to associate this with your preferred svn/cvs tools or programming languages, but rather think of it as something that should/can be applied to any tools and programming languages.

raven
  • 18,004
  • 16
  • 81
  • 112
His
  • 5,891
  • 15
  • 61
  • 82
  • Someone at your work is too pedantic, I hope it isn't you. Whoever it is should consider the present perfect vs. the present imperfect, and the philosophical conundrum of whether the commit comment is read as if from the time it was type, or the time it was itself persisted to the repository. If the latter, use present perfect for a completed action. If the former, use imperfect for an incompleted present activity. – Heath Hunnicutt Nov 18 '09 at 05:27
  • Dupe: http://stackoverflow.com/questions/43598/suggestions-for-a-good-commit-message-format-guideline – bzlm Nov 18 '09 at 08:43
  • 1
    Not a dupe of that question. This is asking about one small aspect, not overall guidelines. –  Nov 20 '09 at 17:26
  • 4
    Fortunately, it is not. I was asking, trying to find out, would like to know what is the general practice out there. If I have to tell you the truth, this is actually the most insignificant question I have ever asked on SO, but hey, it is still a question, isn't it? The question itself has gained three votes, which (if not obvious to you) tells that I am not the only one out there who is thinking that this question is valid in itself. I am after constructive answers and you are not being helpful at all. – His Nov 27 '09 at 00:48
  • 2
    If you thought that people shouldn't worry too much about tenses in commit messages, well say it, state your reasons and your preferences. Much more useful and helpful than your sarcastic comment above. – His Nov 27 '09 at 00:49
  • calm down dude, it's not a serious question (I'm not saying it isn't a valid question) and they were joking around with it. Lighten up. – tster Dec 10 '09 at 23:22
  • 12
    I take this question very seriously. Its a great question. Being consistent is very important when developing software, and being so should be of interest to all the visitors interested in the topic of this website. That is my opinion. – Niklas Berglund Jul 26 '10 at 09:43
  • Similar question: http://stackoverflow.com/questions/3580013/should-i-use-past-or-present-tense-in-git-commit-messages – wip Sep 09 '13 at 02:12
  • See also http://www.exquisitetweets.com/collection/hugovk/1258 http://english.stackexchange.com/q/6602/9001 http://programmers.stackexchange.com/q/56031/25708 http://programmers.stackexchange.com/q/157590/25708 http://stackoverflow.com/q/3580013/724176 – Hugo Jun 18 '14 at 06:31

12 Answers12

40

I think of these messages as they appear to other developers. They don't yet have the changes applied, and there is the implicit question, "what will applying this changeset/patch do?" It will "Fix the XXX bug in YYY"!

For other verbs writing them as a command seems more natural, and works better if you have a specific goal up-front—you can literally write the commit summary along with up-front tests before the work is done.

I don't put a huge amount of weight on it, but for me this is the path of least resistance while maintaining consistentency.

Luke Girvin
  • 13,221
  • 9
  • 64
  • 84
  • 8
    I remember coming across something in the git documentation strongly recommending this tense, but I still find in awkward. – keithjgrant Nov 20 '09 at 17:06
  • 1
    [This](http://stackoverflow.com/a/3580764/1127485) is the piece of Git documentation is comes from. – sschuberth Jul 29 '14 at 10:30
31

I personally go with past tense ("fixed") since by the time I get to committing the bug is fixed (or I wouldn't be committing).

cletus
  • 616,129
  • 168
  • 910
  • 942
12

I prefer to see commit messages in present tense. That way the message describes what the diff does (because you might pull that diff or even that whole commit into a different branch). Thus, the commit message does not describe what it "did" do... It describes what the commit itself "does" do. So it should be in present tense.

Imagine looking at a diff in isolation and trying to decide whether you will apply it. It makes no sense for it to have a title in the past tense.

Lernkurve
  • 20,203
  • 28
  • 86
  • 118
TedPavlic
  • 211
  • 3
  • 6
  • 1
    "what the diff does" but the diff is created by a commit which was __commited__, it's in the git history already, so it was already "applied". – Iulian Onofrei Oct 03 '16 at 11:51
9

IMHO if you want it to be descriptive without need to consider the context, then "Fixed" is definitely the only right variant.

Regarding the intuitiveness - if I look at some changelog I will definitely understand that you mean the bug fixed as I know the context in which the word is used, but my brain will catch it much more quickly if the word is written in this self-specifying way.

"Fixing" is the worst choice IMHO as it can be interpreted not only as describing what the patch does (is for) but as a bug status as well which would mean that it is being worked at and is not yet solved.

Ivan
  • 63,011
  • 101
  • 250
  • 382
8
Fix the XXX bug in YYY
Teach the XXX to be more ZZZ
Correct typos in javadoc

In general: {imperative verb} the {affected object} {optional qualifiers}

Imperative form fits all use cases when I'm considering a patchset.

  • What are you going to do here?
  • What does this patchset do?
  • Why was this patchset created? (to fix the xxx bug...)
  • I need to fix the xxx bug in yyy. Is there a commit on another branch that does this already?

Regardless of your choice, I find consistency helps readability immensely. Pick one and stick with it.

Phil Hord
  • 12,780
  • 1
  • 26
  • 30
  • 5
    Very good reasons. I always consider it as if the message is saying "I am a patch and I [message]". That way you always start with an imperative verb. – florisla Jul 26 '13 at 10:29
5

I think that writing about the current commit in present tense is a good idea, because it makes it more clear when you refer to prior commits in the past tense.

Ken Bloom
  • 57,498
  • 14
  • 111
  • 168
  • 1
    I agree. If the commit refers to itself it is also true, as in "This commit fixes the F00F bug". – bzlm Nov 18 '09 at 08:40
4

I don't think it really matters. The purpose is to:

1) Convey what is or was being done, so bugs can be found easier, problems can be reverted easier, and generally be able to maintain the project easier.

2) Convey what tickets were fixed if any, so auditors (if they're used in you company can see what changes correspond to which tickets).

Lastly, if it's' already been fixed, "Fixing" doesn't make sense, and if you're still working on it, "Fixed" isn't correct.

Reverend Gonzo
  • 39,701
  • 6
  • 59
  • 77
  • 1
    Sure, strictly speaking, it is true that it doesn't really matter. But if you have to pick one, when you have fixed a bug in your local tree and want to commit the changes made, do you say "Fixed XXX" or "Fixes XXX" or "Fix XXX"? – His Nov 18 '09 at 05:42
  • 1
    I think it matters if the text is too brief. Sometimes I see commit messages that make me wonder whether 1. a bug was found or actually fixed, or 2. whether a fix was concieved or actually applied, or 3. whether complex erroneous behavior was partially or actually fully fixed. And sometimes several commits relate to the same bug. In "This commit fixes the bouncy problem in DrawBall() and closes ticket 666" the tense doesn't matter, because the text is verbose. But for "DrawBall() bounces wrong", what did the commit do? – bzlm Nov 18 '09 at 08:39
2

"Fix bug X" is 2 characters shorter than "Fixed bug X".
And 3 shorter than "Fixing bug X".

From the point of view of writing-short-commit-messages, the present tense sometimes / usually saves a few characters?
Which I actually think matters a little little bit e.g. with Git's recommendation of less-than-50-chars-on-the-first-commit-message-line.
Also, less text --> done reading quicker?

KajMagnus
  • 11,308
  • 15
  • 79
  • 127
1

A commit message describes why you wrote the code that is being committed.

"Fixed issue 3124", or "Fixes issue 3124" seems right because it says this code fixed|fixes issue 3124.

However, the grammar may also depend on why marks the bug as fixed. If you can mark the bug as fixed after committing, then "Fixed" is just fine, but if the bug is going to be marked as fixed by someone else after they verify your code, then "Fixes" may be more appropriate.

Parag
  • 12,093
  • 16
  • 57
  • 75
1

I think "Fixes XXX bug" makes more sense than "Fix XXX bug" if the reason for using the present tense is to "make it more descriptive of what the commit does" rather than what the committer did.

technophyle
  • 7,972
  • 6
  • 29
  • 50
0

I think the most important answer to such a question is: Everybody should use what works for a specific project and keep it at least a tiny bit consistent.

While I see the advantages of using the present tense (and in fact stumbled upon this post because I’ve seen some present tense messages in open source projects), I probably never won’t use the present tense for my projects. It’s the recommended way for Linux and Git, and probably other bigger open source projects, but I honestly don’t care as long as I’m not part of these projects.

I’m an indie dev and I use the first line of a commit message for release notes while the description in the following lines gives me an idea about implementation details. It’s a user centric workflow compared to the present tense, developer based approach. I can save some time this way. It would be extremely unnatural to give my users instructions in the release notes. It’s my job to fix bugs and to add features. I have to save time, because I’m an indie. I don’t have a “release notes writer” in my team.

Use the rules of a project if they’re already established, but stay pragmatic, and do whatever will make your work easier or faster.

Rafael Bugajewski
  • 1,702
  • 3
  • 22
  • 37
-4

If it is a small commit I use present continuous:

Fixing bug 304

or

Adding comments

If it is a big commit, I do more of a change log:

  • Fixes Bug 453, 657 and 324
  • Adding Expression syntax
  • Refactored the Operator class.
tster
  • 17,883
  • 5
  • 53
  • 72