Imperative makes way more sense when you're a maintainer and for people forking, etc.

When I merge changes from someone, the commits are always imperative. If there are two approaches taken, say "Use <method a> to foobar" and "Use <method b> to foobar", then the imperative case makes way more sense.

From my perspective, picking a commit to my preferred method is very wonky when it says, "Used <method a> to foobar".

Past-tense is about the what the programmer did to get to the patch, present (imperative...) tense to me is describing in the absolute what is a diff is doing (it describes the act of `git am` this patch).

While the past tense makes sense from the author point of view describing what just happened until they typed `git commit`, I'm in the "present" camp since I find it more relevant to me when reading `git show <rev>`: it tells me what the commit is doing at this particular point in history. I don't really care about the programmer/author centric point of view at the time the message was written.

Past tense is not necessarily programmer-centric. Release notes are generally written in the past tense (with headings like Added/Changed/Removed). If commits are written in the past tense and from the user's point of view they can be used pretty directly to create the release notes.

> it tells me what the commit is doing at this particular point in history

When I talk about a particular point in _history_, I use past tense. :)

> Past tense is not necessarily programmer-centric. Release notes are generally written in the past tense (with headings like Added/Changed/Removed).

... which makes past-tense release notes "team-centric". In other words, past-tense release notes are about justifying the work that was done (like some kind of work report), rather than being an exhaustive list of changes in the application behavior brought by a new version.

> If commits are written in the past tense and from the user's point of view they can be used pretty directly to create the release notes.

Bad idea IMHO.

Making developers worry about their commit messages potentially being used "pretty directly" as release note lines seems dangerous:

- It implicitly convey the idea that commits and release note lines should have the same granularity. This might be true in some cases for programming error fixes, but it's generally not for features.

- What about confidential stuff? commit messages are going to get a lot less informative if there's technically relevant stuff that programmers can't mention anymore (like the names of other customers, the yet-to-be-announced next product, etc.).

Why do you think release notes are "team-centric"? Who do you think release notes are for?

https://www.mozilla.org/en-US/firefox/66.0/releasenotes/

> When I talk about a particular point in _history_, I use past tense. :)

When you read a novel written in the present tense, you don't assume it tells a story that is currently happening right? ;)

The simple rule is to pretend all commits start with "once committed, this change will ..." Or more simply, "this will ..."

I feel the same. For personal projects, unless make a conscious effort, my natural tendency is to use past tense.

As a result, some of my projects have a mix of differently-tensed commit messages, e.g. ones starting with "Fix..." and "Fixed...", etc.

I no longer worry about verb tense, simply using whatever sounds best to me when writing that particular commit message. My messages don't match each other, but so what? They're readable and to the point. Why waste time worrying about something that just doesn't matter?

By yourself it doesn't matter but when you work with teams it is nice to have a consistent style. It's like asking why we have style linters, brand guideline books, and so forth. They're not strictly necessary but it makes things more pleasant to work with. And it takes zero effort to use the imperative.

Imperative vs past is a stylistic issue and in the end doesn't impact how the commit message is understood.

My understanding is that pull request is a GitHub-ism. What git itself has is `git format-patch`, which does exactly what it says on the tin.

> My understanding is that pull request is a GitHub-ism.

It is, but git has a command called request-pull[1]. Linus Torvalds has said[2] that certain aspects of the Github pull request process are not suitable or make it very difficult to submit patchsets for review for the linux kernel and that they should have followed the implemention used in git-request-pull instead.

[1] https://git-scm.com/docs/git-request-pull

[2] https://github.com/torvalds/linux/pull/17#issuecomment-56546...

Didn't know about request-pull, thanks!

I find Scandinavians are much better English speakers than they give themselves credit for (they are sometimes deeply apologetic about immaculate English). Idioms, however, are the hardest part about any language and in English they are hard to nail without painstaking dedication to that language, to the exclusion of native speech in other languages. And that's how you get idioms like pull request, or Ace of Base "All that she wants / is another baby". The latter is supposed to mean "another lover" but it conveys "another pregnancy".

Linus and I are equally Scandinavian, so please let me take this and run with it: The one brief, shining splitsecond of my life where I may actually have perceived something clearer than he did.

You are right, of course. Idioms are eminently slip-upable, especially - I would guess - for someone coming from a closely related language with many fixed expressions beguilingly close, just not quite as close as they may sound on first hearing.

Present-tense tends to be shorter (e.g. “add” vs. “added”). Past-tense phrases add characters that eat up space in a one-liner that might be used for other info.