How to wrap git commit comments?

A

15

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.

Athalee answered 22/1, 2010 at 19:39 Comment(7)

How unfortunate that there seems to be no "good" answer to this question. – Doll 27/10, 2011 at 17:28

The solution in this article is helpful for me: iamnearlythere.com/wrapping-lines-git-diff – Fianna 13/3, 2013 at 8:4

If you really just want a quick way to see the full comments, I think gitk is worth mentioning. – Shoe 7/6, 2013 at 5:3

It is obligatory for me to mention stopwritingramblingcommitmessages.com Big pet peeve. Tools should not coddle or enable others to create low quality output. Love your work and make it beautiful. – Subdeacon 9/10, 2015 at 13:24

Simplest answer: use -S + Enter when viewing the git log. Details in my answer here: https://mcmap.net/q/242252/-how-to-wrap-git-commit-comments – Breechcloth 10/1, 2018 at 21:10

@Subdeacon 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. – Castera 3/2, 2021 at 19:35

That is your opinion. Many Unix developers would disagree I'm sure. – Subdeacon 12/2, 2021 at 18:54

S

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.

Spongy answered 22/1, 2010 at 19:51 Comment(5)

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. – Loreenlorelei 22/1, 2010 at 19:59

@Jörg: true. I have updated my answer to mention the first line length. – Spongy 22/1, 2010 at 20:8

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. – Marsipobranch 3/12, 2010 at 12:11

For more on proper formatting: programmers.stackexchange.com/questions/149199/… and programmers.stackexchange.com/questions/148677/… – Spongy 18/5, 2012 at 23:28

"git log does not do any kind of wrapping": out-of-date? – Banns 7/12, 2012 at 18:49

L

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.

Legality answered 14/7, 2011 at 17:35 Comment(8)

+1 for "you can scroll right and left using arrow keys" - thanks! – Jamnes 3/11, 2011 at 2:25

How do I reverse this. Its not doing exactly what I want. – Sapiential 3/8, 2012 at 14:19

open your ~/.gitconfig file and remove the [core] pager = ... part – Legality 14/8, 2012 at 23:35

Thanks a ton. Is there a place I could read more about core.pager in general? Just if you know off hand. Not asking you to google for me. – Sapiential 28/8, 2012 at 17:1

This answer recommends -R instead of -r. Give it a try if you are noticing some missing lines in your git log output. – Nereid 20/8, 2014 at 14:43

arrow keys don't seem to work on Windows (git bash or cmd.exe) – Mercurate 16/5, 2015 at 5:22

less -r works for me, less -R does not (ubuntu 14.04) – Aney 14/11, 2015 at 22:7

Incidentally, if DON'T want to wrap git log output (say, git log -p with minimized files), you can run git config --global core.pager 'less -S' – Hogback 5/8, 2016 at 18:45

S

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.

Spongy answered 22/1, 2010 at 19:51 Comment(5)

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. – Loreenlorelei 22/1, 2010 at 19:59

@Jörg: true. I have updated my answer to mention the first line length. – Spongy 22/1, 2010 at 20:8

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. – Marsipobranch 3/12, 2010 at 12:11

For more on proper formatting: programmers.stackexchange.com/questions/149199/… and programmers.stackexchange.com/questions/148677/… – Spongy 18/5, 2012 at 23:28

"git log does not do any kind of wrapping": out-of-date? – Banns 7/12, 2012 at 18:49

C

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).

Chiarra answered 11/10, 2012 at 11:31 Comment(1)

piped it to cat, perfecto. – Malachite 16/2, 2014 at 4:10

U

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

Ugaritic answered 3/12, 2010 at 11:54 Comment(1)

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 – Pontifical 23/2, 2011 at 13:9

B

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.)

Banns answered 7/12, 2012 at 18:46 Comment(0)

C

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'

Corporator answered 18/3, 2013 at 16:54 Comment(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) – Copyedit 28/1, 2014 at 14:10

S

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.

Situla answered 24/5, 2013 at 19:23 Comment(0)

C

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

Covington answered 18/1, 2014 at 9:21 Comment(0)

A

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.

Atropos answered 22/4, 2015 at 23:5 Comment(0)

A

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.

Ayeshaayin answered 1/5, 2015 at 2:26 Comment(0)

A

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

Alvarado answered 19/1, 2017 at 10:53 Comment(0)

F

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.

Fleabane answered 9/1, 2018 at 20:9 Comment(0)

B

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

Breechcloth answered 10/1, 2018 at 21:7 Comment(0)

B

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"

Bev answered 5/8, 2015 at 23:59 Comment(0)

C

0

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

Choke answered 21/9, 2016 at 18:52 Comment(0)

Recommended topics

Hot tags