David David - 1 month ago 5
Git Question

How to wrap git commit comments?

Is there a way to wrap git commit comments (when viewed via

git log
), so they are not cut off at the end of the line? It seems like there should be a pretty simple solution, but I haven't been able to find one.



Edit 2011: the other answers (upvoted) highlight the possibility to modify the options less, the default pager used by git.
The remark at the end of my answer still stands: even if you can see long commit message, that doesn't means that other tools having to deal with said (long) message will be able to process them.

Original answer (January 2010) about commit message format policy:

According to this blog, since git log does not do any kind of wrapping, you need to format your comment with an appropriate line length

  • git log doesn't do any special special wrapping of the commit messages.
    With the default pager of less -S, this means your paragraphs flow far off the edge of the screen, making them difficult to read.
    On an 80 column terminal, if we subtract 4 columns for the indent on the left and 4 more for symmetry on the right, we're left with 72 columns.
  • git format-patch --stdout converts a series of commits to a series of emails, using the messages for the message body.
    Good email netiquette dictates we wrap our plain text emails such that there's room for a few levels of nested reply indicators without overflow in an 80 column terminal.

As said here:

In general, use an editor to create your commit messages rather than passing them on the command line. The format should be:

  • A hard wrap at 72 characters
  • A single, short, summary of the commit
  • Followed by a single blank line
  • Followed by supporting details

All sources (including GitPro book, which goes for 50 characters for the first line, as Jörg W Mittag comments) insist on the necessity to wrap yourself the comment, certainly because, even if Git was able to deal with long lines, other tools in the processing chain (email, patches, ...) may not.