75

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.

Thanks.

David
  • 2,027
  • 3
  • 19
  • 21
  • 3
    How unfortunate that there seems to be no "good" answer to this question. – titaniumdecoy Oct 27 '11 at 17:28
  • 1
    The solution in this article is helpful for me: http://iamnearlythere.com/wrapping-lines-git-diff/ – satoru Mar 13 '13 at 08:04
  • If you really just want a quick way to see the full comments, I think gitk is worth mentioning. – erictheavg Jun 07 '13 at 05:03
  • It is obligatory for me to mention http://stopwritingramblingcommitmessages.com/ Big pet peeve. Tools should not coddle or enable others to create low quality output. Love your work and make it beautiful. – Sukima Oct 09 '15 at 13:24
  • Simplest answer: use `-S` + Enter when viewing the git log. Details in my answer here: https://stackoverflow.com/a/48196094/4561887 – Gabriel Staples Jan 10 '18 at 21:10
  • @Sukima In this century, data with hard-wrapped lines is not beautiful, it's ugly. Different devices, different users, different windows will have a different ideal line width. Data shouldn't hard-wire formatting. IMO this is a design flaw in Git. – Kevin Feb 03 '21 at 19:35
  • That is your opinion. Many Unix developers would disagree I'm sure. – Sukima Feb 12 '21 at 18:54

15 Answers15

52

Or you can change your pager to use less -R

$ git config --global core.pager 'less -R'

This will tell less to stop trying to control how the screen is formatted (you can normally scroll right and left during a git log using arrow keys). And as the less manual says "Thus, various display problems may result, such as long lines being split in the wrong place." Which is what you want, you want the line ending to appear at the right of your screen (the wrong place) instead of where the comment author put it.

Also to note, pressing the right arrow key without modifying your pager, will let you see more of the code. Which is my preferred method.

Robert
  • 14,999
  • 4
  • 39
  • 46
35

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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • The first line should be more like 50-60: it is used as the title for e-mails, for example, which may be prefixed with the author name in e-mail clients or where the mailinglist software may prepend the list name or that are tagged with `[PATCH]` or some such. – Jörg W Mittag Jan 22 '10 at 19:59
  • @Jörg: true. I have updated my answer to mention the first line length. – VonC Jan 22 '10 at 20:08
  • 9
    This is one more good excuse to learn Vim; when set as the editor for Git commit messages, Vim will highlight only the first 50 characters of the first line, will flag in red any characters on the second line, and will automatically wrap following lines at 72 characters. – Mark Rushakoff Dec 03 '10 at 12:11
  • 1
    For more on proper formatting: http://programmers.stackexchange.com/questions/149199/why-do-some-open-source-projects-do-not-accept-pull-requests-but-emailing-patch and http://programmers.stackexchange.com/questions/148677/why-is-80-characters-the-standard-limit-for-code-width – VonC May 18 '12 at 23:28
  • 1
    "git log does not do any kind of wrapping": [out-of-date](http://stackoverflow.com/a/13769138/435522)? – alexei Dec 07 '12 at 18:49
19

There doesn't seem to be any perfect way. A workaround I use is just to pipe the output to more (or less, or cat etc.):

git log | more

That wraps the long lines at least on my system (however, you miss the color formatting).

Carl
  • 937
  • 10
  • 21
17

Mentioned in the previous answer is that the default pager (often 'less') is responsible for wrapping and by default it generally chops long lines.

To modify this without changing your commit messages (less and bash example):

$ echo $LESS
-FRSX

This was what I had by default, now to overwrite the LESS environment variable.

echo "LESS=-FRX;export LESS" >> ~/.bash_profile
source ~/.bash_profile
Arrowmaster
  • 9,143
  • 2
  • 28
  • 25
waldo
  • 620
  • 1
  • 5
  • 14
  • 7
    Look out! `echo "LESS=-FRX;export LESS" > ~/.bash_profile` will replace the content of `~/.bash_profile` Use ">>" instead: `echo "LESS=-FRX;export LESS" >> ~/.bash_profile` –  Feb 23 '11 at 13:09
14

At least in git version 1.7.9.5, git log does support line wrapping. From git help log:

 PRETTY FORMATS
   %w([<w>[,<i1>[,<i2>]]]): switch line wrapping

So, for example, the following wraps the long subjects at 72 columns:

alias gl='git log --format="%C(yellow)%h %an %ad%C(reset)%n%w(72,1,2)%s"'

(Agreed that commit formatting conventions should be followed instead of relying on this. However, this might prove useful until the day comes when everybody knows and respects the conventions.)

alexei
  • 2,031
  • 1
  • 26
  • 28
14

Note that less -r (as recommended above) leads to less forgetting its line count and you miss commits because your topmost lines will scroll out of sight! The real fix is disabling the -S option that git enables by default if the LESS environment variable is not set.

A good fix is changing your git config in the following way:

git config --global core.pager 'less -+S'
MatzeBraun
  • 420
  • 4
  • 8
  • 1
    i have no idea what this means, but it fixed my problem where commits _following_ long messages weren't showing up on the next line, but rather continuing on the same line as the last commit (played havok with `--graph`) _(Windows)_ – drzaus Jan 28 '14 at 14:10
4

This has helped me.

git --no-pager log WhateverBranch | head -n40

Typically the branch is large, so, piping it to head and using the -n switch lets you grab only the most recent 40 (or however many) lines of output that you need, and it should wrap (no need to scroll). Be aware this approach also lacks the color formatting.

2

As VonC mentioned, you may want to wrap your commit messages to 72 characters and kill many birds with one stone. This git hook auto-wraps your commit messages and works with any editor: https://github.com/surabhigupta/AutoWrapSeventyTwo

sur
  • 51
  • 4
2

Using this format made my life happier:

log --pretty=format:\"%w(80,1,41)%h - %an, %ar : %s\"

Since the fields in the output ahead of the commit message totaled about 39 characters for most of my commits, it makes reading a lot easier.

Art Smith
  • 77
  • 2
1

Personal suggestion is be simple. When you want to see the full lines in the less pager just type -S this will change to folding the lines or back should you wish to view a section that way.

1

So I was looking for a solution to a similar problem to this, and came across this question. In my case I'm running git show and I have 2 lines where the change is in a single word, towards the end of a very long line. I ended up solving this with a similar approach to how I do with git diff, using the --word-diff-regex option.

git show --color --word-diff-regex="[^[:space:],]+" 55de9c954d5d74a185879d3441a69cc1889c00f1 |more

sibaz
  • 1,242
  • 14
  • 26
1

This is how I solved for wrapping git log messages, for those who are still looking for answers:

git log --pretty=format:"@%H,%cn,%cD,%B" <file name> | tr "\n" " "|tr "@" "\n"

The output of the git log command is piped that finds the newline and replaces with a white space. This is the logic used to join commit messages as a single line.

Here, I am using "@" as a delimiter to differentiate between the commits. You can replace it with whatever special symbol you want. "%H" represents commit hash, "%cn" represents committer name, "%cD" represents commit date, and "%B" raw body message. If you want to know more about pretty=format, please take a look at https://git-scm.com/docs/pretty-formats

Please note that this may not work if you have newline character within git commit message.

The Voyager
  • 617
  • 8
  • 21
1

SHORT ANSWER:
Type -S then Enter when viewing the git log.

DETAILED ANSWER:
git log outputs using the less text viewer, so simply type -S then Enter to toggle between the two line-wrapping modes of "Chop long lines" and "Fold long lines." The "Fold long lines" option enables word wrap.

Source that helped me learn this: https://superuser.com/a/272826/425838

Gabriel Staples
  • 36,492
  • 15
  • 194
  • 265
0

If nano is your preferred editor, then you can set up git to use nano with automatic wrapping at e.g. 72 characters:

git config --global core.editor "nano -r 72"
Craig McQueen
  • 41,871
  • 30
  • 130
  • 181
0

For those using SourceTree, there's a setting (Options > General) that will show a column guide in the commit message:

commit guide settings in SourceTree

commit guide example

cyberbit
  • 1,345
  • 15
  • 22