pretty-formats.txt 7.78 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13
PRETTY FORMATS
--------------

If the commit is a merge, and if the pretty-format
is not 'oneline', 'email' or 'raw', an additional line is
inserted before the 'Author:' line.  This line begins with
"Merge: " and the sha1s of ancestral commits are printed,
separated by spaces.  Note that the listed commits may not
necessarily be the list of the *direct* parent commits if you
have limited your view of history: for example, if you are
only interested in changes related to a certain directory or
file.

14 15 16 17 18 19
There are several built-in formats, and you can define
additional formats by setting a pretty.<name>
config option to either another format name, or a
'format:' string, as described below (see
linkgit:git-config[1]). Here are the details of the
built-in formats:
20 21

* 'oneline'
22 23 24 25 26

	  <sha1> <title line>
+
This is designed to be as compact as possible.

27
* 'short'
28 29 30 31 32 33

	  commit <sha1>
	  Author: <author>

	      <title line>

34
* 'medium'
35 36 37

	  commit <sha1>
	  Author: <author>
38
	  Date:   <author date>
39 40 41 42 43

	      <title line>

	      <full commit message>

44
* 'full'
45 46 47 48 49 50 51 52 53

	  commit <sha1>
	  Author: <author>
	  Commit: <committer>

	      <title line>

	      <full commit message>

54
* 'fuller'
55 56

	  commit <sha1>
57
	  Author:     <author>
58
	  AuthorDate: <author date>
59
	  Commit:     <committer>
60
	  CommitDate: <committer date>
61 62 63 64 65

	       <title line>

	       <full commit message>

66
* 'email'
67 68 69

	  From <sha1> <date>
	  From: <author>
70
	  Date: <author date>
71 72
	  Subject: [PATCH] <title line>

73
	  <full commit message>
74

75
* 'raw'
76 77
+
The 'raw' format shows the entire commit exactly as
78
stored in the commit object.  Notably, the SHA-1s are
79 80
displayed in full, regardless of whether --abbrev or
--no-abbrev are used, and 'parents' information show the
81
true parent commits, without taking grafts or history
82
simplification into account.
83

84
* 'format:<string>'
85
+
86
The 'format:<string>' format allows you to specify which information
87 88 89
you want to show. It works a little bit like printf format,
with the notable exception that you get a newline with '%n'
instead of '\n'.
90 91
+
E.g, 'format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"'
92
would show something like this:
93 94
+
-------
95 96 97
The author of fe6e0ee was Junio C Hamano, 23 hours ago
The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<

98
-------
99
+
100 101 102 103 104 105 106 107 108
The placeholders are:

- '%H': commit hash
- '%h': abbreviated commit hash
- '%T': tree hash
- '%t': abbreviated tree hash
- '%P': parent hashes
- '%p': abbreviated parent hashes
- '%an': author name
109 110
- '%aN': author name (respecting .mailmap, see linkgit:git-shortlog[1]
  or linkgit:git-blame[1])
111
- '%ae': author email
112 113
- '%aE': author email (respecting .mailmap, see
  linkgit:git-shortlog[1] or linkgit:git-blame[1])
114
- '%ad': author date (format respects --date= option)
115 116 117
- '%aD': author date, RFC2822 style
- '%ar': author date, relative
- '%at': author date, UNIX timestamp
118 119
- '%ai': author date, ISO 8601-like format
- '%aI': author date, strict ISO 8601 format
120
- '%cn': committer name
121 122
- '%cN': committer name (respecting .mailmap, see
  linkgit:git-shortlog[1] or linkgit:git-blame[1])
123
- '%ce': committer email
124 125
- '%cE': committer email (respecting .mailmap, see
  linkgit:git-shortlog[1] or linkgit:git-blame[1])
126
- '%cd': committer date (format respects --date= option)
127 128 129
- '%cD': committer date, RFC2822 style
- '%cr': committer date, relative
- '%ct': committer date, UNIX timestamp
130 131
- '%ci': committer date, ISO 8601-like format
- '%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 135
- '%e': encoding
- '%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 142
- '%G?': show "G" for a Good signature, "B" for a Bad signature, "U" for a good,
  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 146
- '%gD': reflog selector, e.g., `refs/[email protected]{1}`
- '%gd': shortened reflog selector, e.g., `[email protected]{1}`
147
- '%gn': reflog identity name
148 149
- '%gN': reflog identity name (respecting .mailmap, see
  linkgit:git-shortlog[1] or linkgit:git-blame[1])
150
- '%ge': reflog identity email
151 152
- '%gE': reflog identity email (respecting .mailmap, see
  linkgit:git-shortlog[1] or linkgit:git-blame[1])
153
- '%gs': reflog subject
154 155 156 157
- '%Cred': switch color to red
- '%Cgreen': switch color to green
- '%Cblue': switch color to blue
- '%Creset': reset color
158 159 160 161
- '%C(...)': color specification, as described in color.branch.* config option;
  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
162 163
  terminal). `auto` alone (i.e. `%C(auto)`) will turn on auto coloring
  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
René Scharfe's avatar
René Scharfe committed
168
- '%w([<w>[,<i1>[,<i2>]]])': switch line wrapping, like the -w option of
169
  linkgit:git-shortlog[1].
170 171 172 173 174
- '%<(<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.
175 176 177 178
- '%<|(<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
179 180 181 182
- '%>>(<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>)'
183
  respectively, but padding both sides (i.e. the text is centered)
184

185 186 187
NOTE: Some placeholders may depend on other options given to the
revision traversal engine. For example, the `%g*` reflog options will
insert an empty string unless we are traversing reflog entries (e.g., by
188 189 190
`git log -g`). The `%d` and `%D` placeholders will use the "short"
decoration format if `--decorate` was not already provided on the command
line.
191

192
If you add a `+` (plus sign) after '%' of a placeholder, a line-feed
193 194 195 196 197 198 199
is inserted immediately before the expansion if and only if the
placeholder expands to a non-empty string.

If you add a `-` (minus sign) after '%' of a placeholder, line-feeds that
immediately precede the expansion are deleted if and only if the
placeholder expands to an empty string.

200 201 202 203
If you add a ` ` (space) after '%' of a placeholder, a space
is inserted immediately before the expansion if and only if the
placeholder expands to a non-empty string.

204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224
* 'tformat:'
+
The 'tformat:' format works exactly like 'format:', except that it
provides "terminator" semantics instead of "separator" semantics. In
other words, each commit has the message terminator character (usually a
newline) appended, rather than a separator placed between entries.
This means that the final entry of a single-line format will be properly
terminated with a new line, just as the "oneline" format does.
For example:
+
---------------------
$ git log -2 --pretty=format:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973 -- NO NEWLINE

$ git log -2 --pretty=tformat:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973
---------------------
225 226 227 228 229 230 231 232 233
+
In addition, any unrecognized string that has a `%` in it is interpreted
as if it has `tformat:` in front of it.  For example, these two are
equivalent:
+
---------------------
$ git log -2 --pretty=tformat:%h 4da45bef
$ git log -2 --pretty=%h 4da45bef
---------------------