Show full Git commit message in console

40,674

Solution 1

pagers to the rescue

git log | less

Make sure you don't have -S on an alias for less

Also, it is generally considered good practice to limit the width for commit messages. I believe a common standard is 78 chars (IIRC), and most texteditors do a good job of ensuring such style rules (auto formatting your message).

Update: As a reference data point, git-config lists:

gui.commitmsgwidth

   Defines how wide the commit message window is in the git-gui(1). "75" 
   is the default.

Solution 2

You can also use

git log --format=<format> [hash|HEAD]

where <format> can be one of the following:

The placeholders are:

# see man git-log PRETTY FORMATS section
%H: commit hash
%h: abbreviated commit hash
%T: tree hash
%t: abbreviated tree hash
%P: parent hashes
%p: abbreviated parent hashes
%an: author name
%aN: author name (respecting .mailmap, see git-shortlog(1) or git-blame(1))
%ae: author email
%aE: author email (respecting .mailmap, see git-shortlog(1) or git-blame(1))
%ad: author date (format respects --date= option)
%aD: author date, RFC2822 style
%ar: author date, relative
%at: author date, UNIX timestamp
%ai: author date, ISO 8601-like format
%aI: author date, strict ISO 8601 format
%cn: committer name
%cN: committer name (respecting .mailmap, see git-shortlog(1) or git-blame(1))
%ce: committer email
%cE: committer email (respecting .mailmap, see git-shortlog(1) or git-blame(1))
%cd: committer date (format respects --date= option)
%cD: committer date, RFC2822 style
%cr: committer date, relative
%ct: committer date, UNIX timestamp
%ci: committer date, ISO 8601-like format
%cI: committer date, strict ISO 8601 format
%d: ref names, like the --decorate option of git-log(1)
%D: ref names without the " (", ")" wrapping.
%e: encoding
%s: subject
%f: sanitized subject line, suitable for a filename
%b: body
%B: raw body (unwrapped subject and body)
%N: commit notes
%GG: raw verification message from GPG for a signed commit
%G?: show "G" for a good (valid) signature, "B" for a bad signature, "U" for a good signature with unknown validity, "X" for a good signature that has expired, "Y" for a good signature made by an expired key, "R"
           for a good signature made by a revoked key, "E" if the signature cannot be checked (e.g. missing key) and "N" for no signature
%GS: show the name of the signer for a signed commit
%GK: show the key used to sign a signed commit
%gD: reflog selector, e.g., refs/stash@{1} or refs/stash@{2 minutes ago}; the format follows the rules described for the -g option. The portion before the @ is the refname as given on the command line (so git log
           -g refs/heads/master would yield refs/heads/master@{0}).
%gd: shortened reflog selector; same as %gD, but the refname portion is shortened for human readability (so refs/heads/master becomes just master).
%gn: reflog identity name
%gN: reflog identity name (respecting .mailmap, see git-shortlog(1) or git-blame(1))
%ge: reflog identity email
%gE: reflog identity email (respecting .mailmap, see git-shortlog(1) or git-blame(1))
%gs: reflog subject
%Cred: switch color to red
%Cgreen: switch color to green
%Cblue: switch color to blue
%Creset: reset color
%C(...): color specification, as described under Values in the "CONFIGURATION FILE" section of git-config(1); adding auto, at the beginning will emit color only when colors are enabled for log output (by
           color.diff, color.ui, or --color, and respecting the auto settings of the former if we are going to a terminal).  auto alone (i.e.  %C(auto)) will turn on auto coloring on the next placeholders until the color is
           switched again.
%m: left (<), right (>) or boundary (-) mark
%n: newline
%%: a raw %
%x00: print a byte from a hex code
%w([<w>[,<i1>[,<i2>]]]): switch line wrapping, like the -w option of git-shortlog(1).
%<(<N>[,trunc|ltrunc|mtrunc]): make the next placeholder take at least N columns, padding spaces on the right if necessary. Optionally truncate at the beginning (ltrunc), the middle (mtrunc) or the end (trunc) if
           the output is longer than N columns. Note that truncating only works correctly with N >= 2.
%<|(<N>): make the next placeholder take at least until Nth columns, padding spaces on the right if necessary
%>(<N>), %>|(<N>): similar to %<(<N>), %<|(<N>) respectively, but padding spaces on the left
%>>(<N>), %>>|(<N>): similar to %>(<N>), %>|(<N>) respectively, except that if the next placeholder takes more spaces than given and there are spaces on its left, use those spaces
%><(<N>), %><|(<N>): similar to % <(<N>), %<|(<N>) respectively, but padding both sides (i.e. the text is centered) -%(trailers): display the trailers of the body as interpreted by git-interpret-trailers(1)

This gives you so much more control over what to extract. For example in my use-case I'm interested in the actual commit message so that I can run a post-commit hook.

# get the raw body of the commit
git log --format=%B HEAD

Solution 3

I use

git lg | fold --width=1000

where lg is defined in .gitconfig like so

[alias]
    lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative

It looks like that:

git log showing full comments wrapping in terminal

Solution 4

You'll just need to disable the pager.

git --no-pager log

This I got from How do I export a git log to a text file?

Solution 5

git log doesn’t support wrapping commit messages, so common practice is is to wrap your commit messages to about 72 characters. See this answer for more discussion.

You should be able to use the arrow keys to scroll left and right to see the remainder of the line, though. Can you?


FWIW, I’m proposing a change to Git that would allow log and the like to wrap commit messages, if you don’t have any other need to wrap them in advance. Watch here and here on the git mailing list to find out if it goes anywhere.

Share:
40,674
alexdmejias
Author by

alexdmejias

Web Dev.

Updated on July 09, 2022

Comments

  • alexdmejias
    alexdmejias almost 2 years

    I'm trying to output the full commit message in the console and I am able get the message, however in order to see the full message I have to keep resizing the console window in order to reveal more. I am on Windows using Cygwin.

    The command I'm using is git log --pretty=full.

  • sehe
    sehe over 12 years
    what do which less and type less say?
  • alexdmejias
    alexdmejias over 12 years
    Not sure I understand, but git log | less outputted commit hash \n author \n date \n\n commit messages (unwrapped)
  • Cascabel
    Cascabel over 12 years
    Git should spawn the pager by default anyway, since git log produces output longer than the terminal height. Also, even if you do have -S on, so that lines are "chopped", you can still see them by pushing left/right arrows.
  • sehe
    sehe over 12 years
    @Jefromi: my guess: the default pager was not triggered (too few lines) or it was configured to use -S
  • Cascabel
    Cascabel over 12 years
    @sehe: Yeah, it'll include -S by default, since it's kind of crazy to wrap code in diffs. Sounds like the real problem is that the commit messages were too wide, anyway.
  • sehe
    sehe over 12 years
    @Jefromi: yup that was my suggestion too. I think it is mentioned in a number of introductory git texts
  • sehe
    sehe over 11 years
    I just realized that it also probably good to use git cat-file -p COMMITID, which will not run through a pager
  • Eric
    Eric over 8 years
    You always have more on Windows: git log | more
  • Jordan McQueen
    Jordan McQueen almost 6 years
    The common standard is 72 characters, because it is centered with 4 spaces on either side. 8 less of the standard 80 character line-width is 72.
  • RockyRoad
    RockyRoad about 3 years
    This is the key. Note that pager is automatically disabled when redirecting the output of git log. Hence git log > /tmp/commit.md to a file, git log | cat to the screen, or even git log | \less with no or custom options.
  • Marslo
    Marslo almost 3 years
    --format=%B is much better than --format="%s%n%n%b". thanks!