57

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.

4b0
  • 21,981
  • 30
  • 95
  • 142
alexdmejias
  • 1,399
  • 4
  • 19
  • 34
  • I found this in the doc page but I dont know how to implement it _-w[[,[,]]] Linewrap the output by wrapping each line at width. The first line of each entry is indented by indent1 spaces, and the second and subsequent lines are indented by indent2 spaces. width, indent1, and indent2 default to 76, 6 and 9 respectively._ [link](http://schacon.github.com/git/git-log.html) – alexdmejias Jan 11 '12 at 18:53
  • You’re quoting the manpage for [git-shortlog](http://schacon.github.com/git/git-shortlog.html), which *does* support line wrapping (but it only shows one line of the commit message). – s4y Jan 11 '12 at 20:54
  • @Sidnicious you are right, here is the text from the log page _%w([[,[,]]]): switch line wrapping, like the -w option of git-shortlog(1)._ – alexdmejias Jan 11 '12 at 20:58
  • Ah, OK. You can use that when you specify a custom format string for commit messages, but you *can’t* use it with one of the `--pretty` formats. – s4y Jan 11 '12 at 22:02
  • See also `git log --no-expand-tabs --pretty=full` for git 2.9 (June 2016) in [my answer below](http://stackoverflow.com/a/36679169/6309) – VonC Apr 17 '16 at 16:33
  • What I needed was: `git log --pretty=full -p`. – x-yuri May 31 '19 at 15:14

7 Answers7

47

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.
sehe
  • 374,641
  • 47
  • 450
  • 633
  • what do `which less` and `type less` say? – sehe Jan 11 '12 at 19:46
  • Not sure I understand, but `git log | less` outputted commit hash \n author \n date \n\n commit messages (unwrapped) – alexdmejias Jan 11 '12 at 19:50
  • 1
    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. – Cascabel Jan 11 '12 at 21:18
  • @Jefromi: my guess: the default pager was not triggered (too few lines) or it was configured to use -S – sehe Jan 11 '12 at 21:53
  • @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. – Cascabel Jan 11 '12 at 21:59
  • @Jefromi: yup that was my suggestion too. I think it is mentioned in a number of introductory git texts – sehe Jan 11 '12 at 22:17
  • I just realized that it also probably good to use `git cat-file -p COMMITID`, which will not run through a pager – sehe Nov 27 '12 at 07:46
  • You always have more on Windows: `git log | more` – Eric Oct 25 '15 at 17:36
  • 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. – Jordan McQueen Aug 06 '18 at 04:24
24

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
polarise
  • 2,303
  • 1
  • 19
  • 28
14

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

Assaf Shomer
  • 1,429
  • 1
  • 15
  • 21
12

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?

Community
  • 1
  • 1
Kushdesh
  • 1,118
  • 10
  • 16
  • 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. – RockyRoad May 21 '21 at 06:06
6

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.

Community
  • 1
  • 1
s4y
  • 50,525
  • 12
  • 70
  • 98
4

Another option to see more when using git log --pretty=(medium,full,fuller) (meaning when not using a pretty=format), is the ability to remove the space indentation (4 spaces) added at the beginning of each log message (git 2.9, June 2016):

See commit fe37a9c, commit 0893eec (29 Mar 2016) by Junio C Hamano (gitster).
See commit 7cc13c7 (16 Mar 2016) by Linus Torvalds (torvalds).
(Merged by Junio C Hamano -- gitster -- in commit cafef3d, 13 Apr 2016)

pretty: enable --expand-tabs by default for selected pretty formats

"git log --pretty={medium,full,fuller}" and "git log" by default prepend 4 spaces to the log message, so it makes sense to enable the new "expand-tabs" facility by default for these formats.
Add --no-expand-tabs option to override the new default.

The doc now reads:

--expand-tabs=<n>:
--expand-tabs:
--no-expand-tabs:

Perform a tab expansion (replace each tab with enough spaces to fill to the next display column that is multiple of '<n>') in the log message before showing it in the output.
--expand-tabs is a short-hand for --expand-tabs=8, and
--no-expand-tabs is a short-hand for --expand-tabs=0, which disables tab expansion.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
4

If you need to see the full, multi-line message of a single commit use

git show --format=full [hash|HEAD]
Michał Szajbe
  • 8,830
  • 3
  • 33
  • 39