5 ms·

git-log and friends indent the commit message by four spaces on the left, so wrapping at ~72 chars gives it symmetry on 80 column terminals. By wrapping it your

git-log and friends indent the commit message by four spaces on the left, so wrapping at ~72 chars gives it symmetry on 80 column terminals. By wrapping it yourself, you decide where line breaks should be, not the presentation machinery. The optimal human-readable line length is something like 66 characters. It's much easier to quickly scan a log message that's 72 characters wide vs. one that is 200 characters wide.

njonsson 15y ago
Making semantic line breaks (such as for bullets) is understandable, but it still feels wrong that we’re otherwise doing the job of `fold`. I started breaking lines in commit messages because it’s convention, but I still believe this is a tooling issue. This shell script wraps wide commit messages to the width of your console. GIT_PAGER="fold -s -w`stty size | awk '{print $2}'` | less" git log $@
- wnoise 15y ago
  You might be interested in the program "par", which uses dynamic programming to optimize the line breaks, and can automatically handle such things as text prefixed by "> ". http://www.nicemice.net/par/ http://www.nicemice.net/par/
harlanlewis 15y ago
Tangent time! "The optimal human-readable line length" isn't really something that exists, even if we make lots of assumptions about basic stuff like font size, avg word length, and color contrast. Here's a quick study on the reading speed and comprehension of character line lengths (cl) between 35 and 95 for reference: http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp http://psychology.wichita.edu/surl/usabilitynews/72/LineLeng... - most efficient reading (speed/accuracy) at 95cl - line length does not affect comprehension But here's the head spinner: - 60% _preferred_ either 35cl or 95cl - 100% _least preferred_ 35cl (45%) or 95cl (55%) Line length is an easy thing to assume everyone perceives the same way, but even given a consistent environment (definitely not a given in this age of increasingly diverse device dimensions) there's a wide range of preferences with little real impact on readability. Unless, of course, your assumptions about readability clash with the user's preferences or reading environment. Put simply - make your life easy and reduce problems by just letting the user decide.

njonsson 15y ago

Making semantic line breaks (such as for bullets) is understandable, but it still feels wrong that we’re otherwise doing the job of `fold`. I started breaking lines in commit messages because it’s convention, but I still believe this is a tooling issue. This shell script wraps wide commit messages to the width of your console. GIT_PAGER="fold -s -w`stty size | awk '{print $2}'` | less" git log $@

wnoise 15y ago
You might be interested in the program "par", which uses dynamic programming to optimize the line breaks, and can automatically handle such things as text prefixed by "> ". http://www.nicemice.net/par/ http://www.nicemice.net/par/

harlanlewis 15y ago

Tangent time! "The optimal human-readable line length" isn't really something that exists, even if we make lots of assumptions about basic stuff like font size, avg word length, and color contrast. Here's a quick study on the reading speed and comprehension of character line lengths (cl) between 35 and 95 for reference: http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp http://psychology.wichita.edu/surl/usabilitynews/72/LineLeng... - most efficient reading (speed/accuracy) at 95cl - line length does not affect comprehension But here's the head spinner: - 60% _preferred_ either 35cl or 95cl - 100% _least preferred_ 35cl (45%) or 95cl (55%) Line length is an easy thing to assume everyone perceives the same way, but even given a consistent environment (definitely not a given in this age of increasingly diverse device dimensions) there's a wide range of preferences with little real impact on readability. Unless, of course, your assumptions about readability clash with the user's preferences or reading environment. Put simply - make your life easy and reduce problems by just letting the user decide.