6 ms·

The repository does not follow its own guidelines. Also, there's a lot of unnecessary stuff in there. Capitalization and imperative? Not at the top of my list.

The repository does not follow its own guidelines. 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/a48494d2fbed58c751e9b7e8fbff88582f9b2d02/README#L88 https://github.com/torvalds/subsurface-for-dirk/blob/a48494d...

js2 7y ago
Or look to git's repo itself for examples: https://github.com/git/git/commits/master https://github.com/git/git/commits/master
dcbadacd 7y ago
I heavily dislike the hard wrap requirement. Why do that if our clients could do it nicely, based on screen size, preference and everything?
- andreareina 7y ago
  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.
  - cjonas 7y ago
    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...
    - buster 7y ago
      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.
    - intertextuality 7y ago
      > 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.
    - deleted 7y ago
      [deleted]
- Reelin 7y ago
  Because very often the client will be some piece of command line tooling that doesn't do those things. https://commit.style 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.
  - int_19h 7y ago
    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.
- u801e 7y ago
  > 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-5660604 https://github.com/torvalds/linux/pull/17#issuecomment-56606....
  - dcbadacd 7y ago
    Let's do markdown in commit messages then. I despise hard wraps everywhere I see them, they work so bad.
hpen 7y ago
Would those relevant points not include the quote about using imperative style? "Header line: explain the commit in one line (use the imperative)"
- red_dinosaur 7y ago
  I don't think the grammatical structure of the sentence matters too much, the important part is "explain the commit in one line".
mikelward 7y ago
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/linux.git/log/ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- thaumasiotes 7y ago
  > 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.
  - massive-tea 7y ago
    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
    - thaumasiotes 7y ago
      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/infinitive https://glossary.sil.org/term/imperative-mood https://glossary.sil.org/term/imperative-mood
      - massive-tea 7y ago
        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.
voiceofunreason 7y ago
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.

js2 7y ago

Or look to git's repo itself for examples: https://github.com/git/git/commits/master https://github.com/git/git/commits/master

dcbadacd 7y ago

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

andreareina 7y ago
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.
- cjonas 7y ago
  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...
  - buster 7y ago
    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.
  - intertextuality 7y ago
    > 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.
  - deleted 7y ago
    [deleted]
Reelin 7y ago
Because very often the client will be some piece of command line tooling that doesn't do those things. https://commit.style 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.
- int_19h 7y ago
  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.
u801e 7y ago
> 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-5660604 https://github.com/torvalds/linux/pull/17#issuecomment-56606....
- dcbadacd 7y ago
  Let's do markdown in commit messages then. I despise hard wraps everywhere I see them, they work so bad.

hpen 7y ago

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

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

mikelward 7y ago

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/linux.git/log/ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

thaumasiotes 7y ago
> 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.
- massive-tea 7y ago
  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
  - thaumasiotes 7y ago
    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/infinitive https://glossary.sil.org/term/imperative-mood https://glossary.sil.org/term/imperative-mood
    - massive-tea 7y ago
      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.

voiceofunreason 7y ago

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.