Documentation / pretty-formats.txton commit doc: core.ignoreStat clarify the --assume-unchanged effect (1be976e)
   1PRETTY FORMATS
   2--------------
   3
   4If the commit is a merge, and if the pretty-format
   5is not 'oneline', 'email' or 'raw', an additional line is
   6inserted before the 'Author:' line.  This line begins with
   7"Merge: " and the sha1s of ancestral commits are printed,
   8separated by spaces.  Note that the listed commits may not
   9necessarily be the list of the *direct* parent commits if you
  10have limited your view of history: for example, if you are
  11only interested in changes related to a certain directory or
  12file.
  13
  14There are several built-in formats, and you can define
  15additional formats by setting a pretty.<name>
  16config option to either another format name, or a
  17'format:' string, as described below (see
  18linkgit:git-config[1]). Here are the details of the
  19built-in formats:
  20
  21* 'oneline'
  22
  23          <sha1> <title line>
  24+
  25This is designed to be as compact as possible.
  26
  27* 'short'
  28
  29          commit <sha1>
  30          Author: <author>
  31
  32              <title line>
  33
  34* 'medium'
  35
  36          commit <sha1>
  37          Author: <author>
  38          Date:   <author date>
  39
  40              <title line>
  41
  42              <full commit message>
  43
  44* 'full'
  45
  46          commit <sha1>
  47          Author: <author>
  48          Commit: <committer>
  49
  50              <title line>
  51
  52              <full commit message>
  53
  54* 'fuller'
  55
  56          commit <sha1>
  57          Author:     <author>
  58          AuthorDate: <author date>
  59          Commit:     <committer>
  60          CommitDate: <committer date>
  61
  62               <title line>
  63
  64               <full commit message>
  65
  66* 'email'
  67
  68          From <sha1> <date>
  69          From: <author>
  70          Date: <author date>
  71          Subject: [PATCH] <title line>
  72
  73          <full commit message>
  74
  75* 'raw'
  76+
  77The 'raw' format shows the entire commit exactly as
  78stored in the commit object.  Notably, the SHA-1s are
  79displayed in full, regardless of whether --abbrev or
  80--no-abbrev are used, and 'parents' information show the
  81true parent commits, without taking grafts or history
  82simplification into account.
  83
  84* 'format:<string>'
  85+
  86The 'format:<string>' format allows you to specify which information
  87you want to show. It works a little bit like printf format,
  88with the notable exception that you get a newline with '%n'
  89instead of '\n'.
  90+
  91E.g, 'format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"'
  92would show something like this:
  93+
  94-------
  95The author of fe6e0ee was Junio C Hamano, 23 hours ago
  96The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
  97
  98-------
  99+
 100The placeholders are:
 101
 102- '%H': commit hash
 103- '%h': abbreviated commit hash
 104- '%T': tree hash
 105- '%t': abbreviated tree hash
 106- '%P': parent hashes
 107- '%p': abbreviated parent hashes
 108- '%an': author name
 109- '%aN': author name (respecting .mailmap, see linkgit:git-shortlog[1]
 110  or linkgit:git-blame[1])
 111- '%ae': author email
 112- '%aE': author email (respecting .mailmap, see
 113  linkgit:git-shortlog[1] or linkgit:git-blame[1])
 114- '%ad': author date (format respects --date= option)
 115- '%aD': author date, RFC2822 style
 116- '%ar': author date, relative
 117- '%at': author date, UNIX timestamp
 118- '%ai': author date, ISO 8601-like format
 119- '%aI': author date, strict ISO 8601 format
 120- '%cn': committer name
 121- '%cN': committer name (respecting .mailmap, see
 122  linkgit:git-shortlog[1] or linkgit:git-blame[1])
 123- '%ce': committer email
 124- '%cE': committer email (respecting .mailmap, see
 125  linkgit:git-shortlog[1] or linkgit:git-blame[1])
 126- '%cd': committer date (format respects --date= option)
 127- '%cD': committer date, RFC2822 style
 128- '%cr': committer date, relative
 129- '%ct': committer date, UNIX timestamp
 130- '%ci': committer date, ISO 8601-like format
 131- '%cI': committer date, strict ISO 8601 format
 132- '%d': ref names, like the --decorate option of linkgit:git-log[1]
 133- '%D': ref names without the " (", ")" wrapping.
 134- '%e': encoding
 135- '%s': subject
 136- '%f': sanitized subject line, suitable for a filename
 137- '%b': body
 138- '%B': raw body (unwrapped subject and body)
 139- '%N': commit notes
 140- '%GG': raw verification message from GPG for a signed commit
 141- '%G?': show "G" for a Good signature, "B" for a Bad signature, "U" for a good,
 142  untrusted signature and "N" for no signature
 143- '%GS': show the name of the signer for a signed commit
 144- '%GK': show the key used to sign a signed commit
 145- '%gD': reflog selector, e.g., `refs/stash@{1}`
 146- '%gd': shortened reflog selector, e.g., `stash@{1}`
 147- '%gn': reflog identity name
 148- '%gN': reflog identity name (respecting .mailmap, see
 149  linkgit:git-shortlog[1] or linkgit:git-blame[1])
 150- '%ge': reflog identity email
 151- '%gE': reflog identity email (respecting .mailmap, see
 152  linkgit:git-shortlog[1] or linkgit:git-blame[1])
 153- '%gs': reflog subject
 154- '%Cred': switch color to red
 155- '%Cgreen': switch color to green
 156- '%Cblue': switch color to blue
 157- '%Creset': reset color
 158- '%C(...)': color specification, as described in color.branch.* config option;
 159  adding `auto,` at the beginning will emit color only when colors are
 160  enabled for log output (by `color.diff`, `color.ui`, or `--color`, and
 161  respecting the `auto` settings of the former if we are going to a
 162  terminal). `auto` alone (i.e. `%C(auto)`) will turn on auto coloring
 163  on the next placeholders until the color is switched again.
 164- '%m': left, right or boundary mark
 165- '%n': newline
 166- '%%': a raw '%'
 167- '%x00': print a byte from a hex code
 168- '%w([<w>[,<i1>[,<i2>]]])': switch line wrapping, like the -w option of
 169  linkgit:git-shortlog[1].
 170- '%<(<N>[,trunc|ltrunc|mtrunc])': make the next placeholder take at
 171  least N columns, padding spaces on the right if necessary.
 172  Optionally truncate at the beginning (ltrunc), the middle (mtrunc)
 173  or the end (trunc) if the output is longer than N columns.
 174  Note that truncating only works correctly with N >= 2.
 175- '%<|(<N>)': make the next placeholder take at least until Nth
 176  columns, padding spaces on the right if necessary
 177- '%>(<N>)', '%>|(<N>)': similar to '%<(<N>)', '%<|(<N>)'
 178  respectively, but padding spaces on the left
 179- '%>>(<N>)', '%>>|(<N>)': similar to '%>(<N>)', '%>|(<N>)'
 180  respectively, except that if the next placeholder takes more spaces
 181  than given and there are spaces on its left, use those spaces
 182- '%><(<N>)', '%><|(<N>)': similar to '% <(<N>)', '%<|(<N>)'
 183  respectively, but padding both sides (i.e. the text is centered)
 184
 185NOTE: Some placeholders may depend on other options given to the
 186revision traversal engine. For example, the `%g*` reflog options will
 187insert an empty string unless we are traversing reflog entries (e.g., by
 188`git log -g`). The `%d` and `%D` placeholders will use the "short"
 189decoration format if `--decorate` was not already provided on the command
 190line.
 191
 192If you add a `+` (plus sign) after '%' of a placeholder, a line-feed
 193is inserted immediately before the expansion if and only if the
 194placeholder expands to a non-empty string.
 195
 196If you add a `-` (minus sign) after '%' of a placeholder, line-feeds that
 197immediately precede the expansion are deleted if and only if the
 198placeholder expands to an empty string.
 199
 200If you add a ` ` (space) after '%' of a placeholder, a space
 201is inserted immediately before the expansion if and only if the
 202placeholder expands to a non-empty string.
 203
 204* 'tformat:'
 205+
 206The 'tformat:' format works exactly like 'format:', except that it
 207provides "terminator" semantics instead of "separator" semantics. In
 208other words, each commit has the message terminator character (usually a
 209newline) appended, rather than a separator placed between entries.
 210This means that the final entry of a single-line format will be properly
 211terminated with a new line, just as the "oneline" format does.
 212For example:
 213+
 214---------------------
 215$ git log -2 --pretty=format:%h 4da45bef \
 216  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
 2174da45be
 2187134973 -- NO NEWLINE
 219
 220$ git log -2 --pretty=tformat:%h 4da45bef \
 221  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
 2224da45be
 2237134973
 224---------------------
 225+
 226In addition, any unrecognized string that has a `%` in it is interpreted
 227as if it has `tformat:` in front of it.  For example, these two are
 228equivalent:
 229+
 230---------------------
 231$ git log -2 --pretty=tformat:%h 4da45bef
 232$ git log -2 --pretty=%h 4da45bef
 233---------------------