Merge branch 'jk/filter-branch-use-of-sed-on-incomplete-line'
[git] / Documentation / pretty-formats.txt
1 PRETTY FORMATS
2 --------------
3
4 If the commit is a merge, and if the pretty-format
5 is not 'oneline', 'email' or 'raw', an additional line is
6 inserted before the 'Author:' line.  This line begins with
7 "Merge: " and the sha1s of ancestral commits are printed,
8 separated by spaces.  Note that the listed commits may not
9 necessarily be the list of the *direct* parent commits if you
10 have limited your view of history: for example, if you are
11 only interested in changes related to a certain directory or
12 file.
13
14 There are several built-in formats, and you can define
15 additional formats by setting a pretty.<name>
16 config option to either another format name, or a
17 'format:' string, as described below (see
18 linkgit:git-config[1]). Here are the details of the
19 built-in formats:
20
21 * 'oneline'
22
23           <sha1> <title line>
24 +
25 This 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 +
77 The 'raw' format shows the entire commit exactly as
78 stored in the commit object.  Notably, the SHA-1s are
79 displayed in full, regardless of whether --abbrev or
80 --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 you want to show. It works a little bit like printf format,
88 with the notable exception that you get a newline with '%n'
89 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 The author of fe6e0ee was Junio C Hamano, 23 hours ago
96 The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
97
98 -------
99 +
100 The 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
185 NOTE: Some placeholders may depend on other options given to the
186 revision traversal engine. For example, the `%g*` reflog options will
187 insert 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"
189 decoration format if `--decorate` was not already provided on the command
190 line.
191
192 If you add a `+` (plus sign) after '%' of a placeholder, a line-feed
193 is inserted immediately before the expansion if and only if the
194 placeholder expands to a non-empty string.
195
196 If you add a `-` (minus sign) after '%' of a placeholder, line-feeds that
197 immediately precede the expansion are deleted if and only if the
198 placeholder expands to an empty string.
199
200 If you add a ` ` (space) after '%' of a placeholder, a space
201 is inserted immediately before the expansion if and only if the
202 placeholder expands to a non-empty string.
203
204 * 'tformat:'
205 +
206 The 'tformat:' format works exactly like 'format:', except that it
207 provides "terminator" semantics instead of "separator" semantics. In
208 other words, each commit has the message terminator character (usually a
209 newline) appended, rather than a separator placed between entries.
210 This means that the final entry of a single-line format will be properly
211 terminated with a new line, just as the "oneline" format does.
212 For example:
213 +
214 ---------------------
215 $ git log -2 --pretty=format:%h 4da45bef \
216   | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
217 4da45be
218 7134973 -- NO NEWLINE
219
220 $ git log -2 --pretty=tformat:%h 4da45bef \
221   | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
222 4da45be
223 7134973
224 ---------------------
225 +
226 In addition, any unrecognized string that has a `%` in it is interpreted
227 as if it has `tformat:` in front of it.  For example, these two are
228 equivalent:
229 +
230 ---------------------
231 $ git log -2 --pretty=tformat:%h 4da45bef
232 $ git log -2 --pretty=%h 4da45bef
233 ---------------------