Also, there's a lot of unnecessary stuff in there. Capitalization and imperative? Not at the top of my list.
The relevant points are nicely summarized by Linus Torvalds: https://github.com/torvalds/subsurface-for-dirk/blob/a48494d...
> 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.
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.
Or simply using a terminal with multiple windows open. I hard wrap at 50 chars and I haven't died from exertion yet.
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....
Use the same spelling conventions as the auto-generated messages seems a reasonable request.
But it does seem like Linux is inconsistent about capitalization. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
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.
In the well-formed sentence
For cyanide to kill you, you need to be exposed to a lethal dose all at once.
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.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.And in the commit message "Add feature X", "add" is likewise an infinitive.
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.
At this point, he has been being investigated for six months.
Are all four of them "main verbs"?