I heavily dislike the hard wrap requirement. Why do that if our clients could do it nicely, based on screen size, preference and everything?

Because very often the client will be some piece of command line tooling that doesn't do those things.

https://commit.style

> Git is strongly opinionated that the author is responsible for line breaks; if you omit them, command line tooling will show it as one extremely long unwrapped line.

The terminal will still wrap that long line.

In general, this approach is broken by design, because the author cannot know where the commit message is going to be displayed. It might actually be in the context where wrapping at 80 or even at 72 is still not long enough (a tooltip in an IDE, say). Or it might be one where it results in a lot of wasted whitespace. It's much better to fix anything that does not handle wrapping properly to do so, than to impose an arbitrary limit that only really works for one environment.

Maximum flexibility with minimum complexity. You want lines that wrap because humans are going to read the message. But you need to be able to not wrap when needed, e.g. when posting code snippets. You need something that any client (including email clients written 10 years before git was a thing) is going to recognize and know how to display correctly. Hard-wrapped plain text fits the bill.

Why would you need to support a commit message in a 10 year old client? This is like saying you need to support IE8 in a web app. If the person doesn't like things being broken, then maybe they should update there software...

> 10 year old client

Or simply using a terminal with multiple windows open. I hard wrap at 50 chars and I haven't died from exertion yet.

The ability to display commit messages nicely probably is not the metric by which people chose their email client. Wrapping text where it makes sense is also a task which is best done by the human writing it. I'd rather have a meaningful text flow with sense than some machine hard wrapping in the mi dle of the sentence.

> Why do that if our clients could do it nicely, based on screen size, preference and everything?

Because there are some thing that shouldn't be soft-wrapped. Like code snippets, diffs, formatted output, etc. It's far easier to let the person who write the commit message to decide where to wrap it rather than relying on the recipient's display to do it for them. Linus Torvalds describes the same issue here [1].

[1] https://github.com/torvalds/linux/pull/17#issuecomment-56606....

Let's do markdown in commit messages then. I despise hard wraps everywhere I see them, they work so bad.

Would those relevant points not include the quote about using imperative style? "Header line: explain the commit in one line (use the imperative)"

I don't think the grammatical structure of the sentence matters too much, the important part is "explain the commit in one line".

What I like about Linus's summary is that it articulates which use cases matter; "here are the tools I am using, make my experience pleasant."

Use the same spelling conventions as the auto-generated messages seems a reasonable request.

Or look to git's repo itself for examples:

https://github.com/git/git/commits/master

That link also says "(use the imperative)".

But it does seem like Linux is inconsistent about capitalization. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

> That link also says "(use the imperative)".

So it does. How are people managing to independently get this so wrong? The form used in a commit message isn't an imperative. It's an infinitive. No commands are being issued. This is like a purported grammar book telling you that third-person singular subjects use plural verb forms when the verb is in the past tense. The form is identical (except, in the example, for was), but the statement is obviously incorrect.

A sentence must have a subject and a predicate, and a verb in the infitive form can't be a predicate (it's usually going to be some kind of complement). 'Fix the bug' is usually taken to be a sentence describing what you meant the commit to do, which is why the imperative is the more likely interpretation.

> A sentence must have a subject and a predicate, and a verb in the inf[in]itive form can't be a predicate

In the well-formed sentence

    For cyanide to kill you, you need to be exposed to a lethal dose all at once.

What do you think "to kill you" is?

Furthermore, idiomatic commit messages are pretty clearly not sentences, so I don't see why you think sentence structure should determine what they contain. And even on your own analysis of how the messages are interpreted (which I agree with), those verbs are infinitive, just as "fix" is infinitive in this dialog:

    Q: What is this patch supposed to do?
    A: Fix issue #351916.

> What do you think "to kill you" is?

Infinitive. The predicate is "need" in this case. Swapping the order might make it clearer:

    You need to be exposed to a lethal dose all at once for cyanide to kill you.

"For cyanide to kill you" is constructed from the sentence "cyanide kills you", and obeys exactly the same rules. It predicates an action (killing) of a particular agent (cyanide), though it is not bound to any particular time. If "kills you" is a "predicate" in the finite clause, then "to kill you" is also a predicate in the nonfinite clause. Can you make the argument that it isn't without special pleading?

The infinitive form of verbs in English always starts with "to", as in "to add", "to fix" etc. That would be a very strange commit message. Imperative is normal: "Add x feature" etc

This is not correct; many infinitives are marked by "to" and many aren't. Such marking may, depending on context, be required, optional, or prohibited. For example, in "this can be a hassle", "be" is an infinitive. There just isn't any way to interpret it as an imperative. Who are you commanding?

And in the commit message "Add feature X", "add" is likewise an infinitive.

https://glossary.sil.org/term/infinitive

https://glossary.sil.org/term/imperative-mood

Eh? "To be" is not the main verb in that sentence so of course it's in infinitive form. "Add feature X" is imperative. "To add feature X" is infinitive.

> "To be" is not the main verb in that sentence ["this can be a hassle"] so of course it's in infinitive form.

This directly conflicts with your earlier statement that

> The infinitive form of verbs in English always starts with "to", as in "to add", "to fix" etc.

That earlier statement is wrong, so contradicting it doesn't really present a problem, but you've left me pretty confused as to what you think you're saying.

Whether "be" is the "main verb" in that sentence is a more interesting question. There's a decent argument that it is, in that "this can be a hassle" is easily viewed as a modified form of the sentence "this is a hassle", but not as a modified form of the defective sentence "this can". But you're correct that the standard analysis just says that "this can be a hassle" is sentence where the subject is "this", the verb is "can", and the object is an infinitive clause.

I thought it went without saying that we're talking about main verbs because verbs in other positions don't change forms anyway.

    At this point, he has been being investigated for six months.

That sentence contains four verbs, of which zero are in the plain form. (One is present-3sg, one is ING-form, and two are EN-form.)

Are all four of them "main verbs"?