1GIT-SHOW(1) Git Manual GIT-SHOW(1)
2
6 git-show - Show various types of objects
7
9 git show [options] <object>...
10
12 Shows one or more objects (blobs, trees, tags and commits).
13 For commits it shows the log message and textual diff. It also presents
15 the merge commit in a special format as produced by git diff-tree --cc.
16 For tags, it shows the tag message and the referenced objects.
18 For trees, it shows the names (equivalent to git ls-tree with
20 --name-only).
21 For plain blobs, it shows the plain contents.
23 The command takes options applicable to the git diff-tree command to
25 control how the changes the commit introduces are shown.
26 This manual page describes only the most frequently used options.
28
30 <object>...
31 The names of objects to show. For a more complete list of ways to
32 spell object names, see "SPECIFYING REVISIONS" section in git-rev-
33 parse(1).
34 --pretty[=<format>], --format[=<format>]
36 Pretty-print the contents of the commit logs in a given format,
37 where <format> can be one of oneline, short, medium, full, fuller,
38 email, raw and format:<string>. When omitted, the format defaults
39 to medium.
40 Note: you can specify the default pretty format in the repository
42 configuration (see git-config(1)).
43 --abbrev-commit
45 Instead of showing the full 40-byte hexadecimal commit object name,
46 show only a partial prefix. Non default number of digits can be
47 specified with "--abbrev=<n>" (which also modifies diff output, if
48 it is displayed).
49 This should make "--pretty=oneline" a whole lot more readable for
51 people using 80-column terminals.
52 --oneline
54 This is a shorthand for "--pretty=oneline --abbrev-commit" used
55 together.
56 --encoding[=<encoding>]
58 The commit objects record the encoding used for the log message in
59 their encoding header; this option can be used to tell the command
60 to re-code the commit log message in the encoding preferred by the
61 user. For non plumbing commands this defaults to UTF-8.
62 --no-notes, --show-notes[=<ref>]
64 Show the notes (see git-notes(1)) that annotate the commit, when
65 showing the commit log message. This is the default for git log,
66 git show and git whatchanged commands when there is no --pretty,
67 --format nor --oneline option is given on the command line.
68 With an optional argument, add this ref to the list of notes. The
70 ref is taken to be in refs/notes/ if it is not qualified.
71 --[no-]standard-notes
73 Enable or disable populating the notes ref list from the
74 core.notesRef and notes.displayRef variables (or corresponding
75 environment overrides). Enabled by default. See git-config(1).
76
78 If the commit is a merge, and if the pretty-format is not oneline,
79 email or raw, an additional line is inserted before the Author: line.
80 This line begins with "Merge: " and the sha1s of ancestral commits are
81 printed, separated by spaces. Note that the listed commits may not
82 necessarily be the list of the direct parent commits if you have
83 limited your view of history: for example, if you are only interested
84 in changes related to a certain directory or file.
85 Here are some additional details for each format:
87 · oneline
89 <sha1> <title line>
91 This is designed to be as compact as possible.
93 · short
95 commit <sha1>
97 Author: <author>
98 <title line>
100 · medium
102 commit <sha1>
104 Author: <author>
105 Date: <author date>
106 <title line>
108 <full commit message>
110 · full
112 commit <sha1>
114 Author: <author>
115 Commit: <committer>
116 <title line>
118 <full commit message>
120 · fuller
122 commit <sha1>
124 Author: <author>
125 AuthorDate: <author date>
126 Commit: <committer>
127 CommitDate: <committer date>
128 <title line>
130 <full commit message>
132 · email
134 From <sha1> <date>
136 From: <author>
137 Date: <author date>
138 Subject: [PATCH] <title line>
139 <full commit message>
141 · raw
143 The raw format shows the entire commit exactly as stored in the
145 commit object. Notably, the SHA1s are displayed in full, regardless
146 of whether --abbrev or --no-abbrev are used, and parents
147 information show the true parent commits, without taking grafts nor
148 history simplification into account.
149 · format:
151 The format: format allows you to specify which information you want
153 to show. It works a little bit like printf format, with the notable
154 exception that you get a newline with %n instead of \n.
155 E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
157 would show something like this:
158 The author of fe6e0ee was Junio C Hamano, 23 hours ago
160 The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
161 The placeholders are:
163 · %H: commit hash
165 · %h: abbreviated commit hash
167 · %T: tree hash
169 · %t: abbreviated tree hash
171 · %P: parent hashes
173 · %p: abbreviated parent hashes
175 · %an: author name
177 · %aN: author name (respecting .mailmap, see git-shortlog(1) or
179 git-blame(1))
180 · %ae: author email
182 · %aE: author email (respecting .mailmap, see git-shortlog(1) or
184 git-blame(1))
185 · %ad: author date (format respects --date= option)
187 · %aD: author date, RFC2822 style
189 · %ar: author date, relative
191 · %at: author date, UNIX timestamp
193 · %ai: author date, ISO 8601 format
195 · %cn: committer name
197 · %cN: committer name (respecting .mailmap, see git-shortlog(1)
199 or git-blame(1))
200 · %ce: committer email
202 · %cE: committer email (respecting .mailmap, see git-shortlog(1)
204 or git-blame(1))
205 · %cd: committer date
207 · %cD: committer date, RFC2822 style
209 · %cr: committer date, relative
211 · %ct: committer date, UNIX timestamp
213 · %ci: committer date, ISO 8601 format
215 · %d: ref names, like the --decorate option of git-log(1)
217 · %e: encoding
219 · %s: subject
221 · %f: sanitized subject line, suitable for a filename
223 · %b: body
225 · %N: commit notes
227 · %gD: reflog selector, e.g., refs/stash@{1}
229 · %gd: shortened reflog selector, e.g., stash@{1}
231 · %gs: reflog subject
233 · %Cred: switch color to red
235 · %Cgreen: switch color to green
237 · %Cblue: switch color to blue
239 · %Creset: reset color
241 · %C(...): color specification, as described in color.branch.*
243 config option
244 · %m: left, right or boundary mark
246 · %n: newline
248 · %%: a raw %
250 · %x00: print a byte from a hex code
252 · %w([<w>[,<i1>[,<i2>]]]): switch line wrapping, like the -w
254 option of git-shortlog(1).
255 Note
257 Some placeholders may depend on other options given to the revision
258 traversal engine. For example, the %g* reflog options will insert
259 an empty string unless we are traversing reflog entries (e.g., by
260 git log -g). The %d placeholder will use the "short" decoration
261 format if --decorate was not already provided on the command line.
262 If you add a + (plus sign) after % of a placeholder, a line-feed is
264 inserted immediately before the expansion if and only if the
265 placeholder expands to a non-empty string.
266 If you add a - (minus sign) after % of a placeholder, line-feeds that
268 immediately precede the expansion are deleted if and only if the
269 placeholder expands to an empty string.
270 · tformat:
272 The tformat: format works exactly like format:, except that it
274 provides "terminator" semantics instead of "separator" semantics.
275 In other words, each commit has the message terminator character
276 (usually a newline) appended, rather than a separator placed
277 between entries. This means that the final entry of a single-line
278 format will be properly terminated with a new line, just as the
279 "oneline" format does. For example:
280 $ git log -2 --pretty=format:%h 4da45bef \
282 | perl -pe ´$_ .= " -- NO NEWLINE\n" unless /\n/´
283 4da45be
284 7134973 -- NO NEWLINE
285 $ git log -2 --pretty=tformat:%h 4da45bef \
287 | perl -pe ´$_ .= " -- NO NEWLINE\n" unless /\n/´
288 4da45be
289 7134973
290 In addition, any unrecognized string that has a % in it is
292 interpreted as if it has tformat: in front of it. For example,
293 these two are equivalent:
294 $ git log -2 --pretty=tformat:%h 4da45bef
296 $ git log -2 --pretty=%h 4da45bef
297
300 git show v1.0.0
301 Shows the tag v1.0.0, along with the object the tags points at.
302 git show v1.0.0^{tree}
304 Shows the tree pointed to by the tag v1.0.0.
305 git show next~10:Documentation/README
307 Shows the contents of the file Documentation/README as they were
308 current in the 10th last commit of the branch next.
309 git show master:Makefile master:t/Makefile
311 Concatenates the contents of said Makefiles in the head of the
312 branch master.
313
315 At the core level, git is character encoding agnostic.
316 · The pathnames recorded in the index and in the tree objects are
318 treated as uninterpreted sequences of non-NUL bytes. What
319 readdir(2) returns are what are recorded and compared with the data
320 git keeps track of, which in turn are expected to be what lstat(2)
321 and creat(2) accepts. There is no such thing as pathname encoding
322 translation.
323 · The contents of the blob objects are uninterpreted sequences of
325 bytes. There is no encoding translation at the core level.
326 · The commit log messages are uninterpreted sequences of non-NUL
328 bytes.
329 Although we encourage that the commit log messages are encoded in
331 UTF-8, both the core and git Porcelain are designed not to force UTF-8
332 on projects. If all participants of a particular project find it more
333 convenient to use legacy encodings, git does not forbid it. However,
334 there are a few things to keep in mind.
335 1. git commit and git commit-tree issues a warning if the commit log
337 message given to it does not look like a valid UTF-8 string, unless
338 you explicitly say your project uses a legacy encoding. The way to
339 say this is to have i18n.commitencoding in .git/config file, like
340 this:
341 [i18n]
343 commitencoding = ISO-8859-1
344 Commit objects created with the above setting record the value of
346 i18n.commitencoding in its encoding header. This is to help other
347 people who look at them later. Lack of this header implies that the
348 commit log message is encoded in UTF-8.
349 2. git log, git show, git blame and friends look at the encoding
351 header of a commit object, and try to re-code the log message into
352 UTF-8 unless otherwise specified. You can specify the desired
353 output encoding with i18n.logoutputencoding in .git/config file,
354 like this:
355 [i18n]
357 logoutputencoding = ISO-8859-1
358 If you do not have this configuration variable, the value of
360 i18n.commitencoding is used instead.
361 Note that we deliberately chose not to re-code the commit log message
363 when a commit is made to force UTF-8 at the commit object level,
364 because re-coding to UTF-8 is not necessarily a reversible operation.
365
367 Written by Linus Torvalds <torvalds@osdl.org[1]> and Junio C Hamano
368 <gitster@pobox.com[2]>. Significantly enhanced by Johannes Schindelin
369 <Johannes.Schindelin@gmx.de[3]>.
370
372 Documentation by David Greaves, Petr Baudis and the git-list
373 <git@vger.kernel.org[4]>.
374
376 Part of the git(1) suite
377
379 1. torvalds@osdl.org
380 mailto:torvalds@osdl.org
381 2. gitster@pobox.com
383 mailto:gitster@pobox.com
384 3. Johannes.Schindelin@gmx.de
386 mailto:Johannes.Schindelin@gmx.de
387 4. git@vger.kernel.org
389 mailto:git@vger.kernel.org
390Git 1.7.1 08/16/2017 GIT-SHOW(1)