Show full Git commit message in console
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:
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.
Comments
-
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 over 12 yearswhat do
which less
andtype less
say? -
alexdmejias over 12 yearsNot sure I understand, but
git log | less
outputted commit hash \n author \n date \n\n commit messages (unwrapped) -
Cascabel over 12 yearsGit 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 over 12 years@Jefromi: my guess: the default pager was not triggered (too few lines) or it was configured to use -S
-
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 over 12 years@Jefromi: yup that was my suggestion too. I think it is mentioned in a number of introductory git texts
-
sehe over 11 yearsI just realized that it also probably good to use
git cat-file -p COMMITID
, which will not run through a pager -
Eric over 8 yearsYou always have more on Windows:
git log | more
-
Jordan McQueen almost 6 yearsThe 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 about 3 yearsThis is the key. Note that pager is automatically disabled when redirecting the output of
git log
. Hencegit log > /tmp/commit.md
to a file,git log | cat
to the screen, or evengit log | \less
with no or custom options. -
Marslo almost 3 years
--format=%B
is much better than--format="%s%n%n%b"
. thanks!