4 ms·

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.

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.