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
33 gitrevisions(7).
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>. See the "PRETTY FORMATS" section
39 for some additional details for each format. When omitted, the
40 format defaults to medium.
41 Note: you can specify the default pretty format in the repository
43 configuration (see git-config(1)).
44 --abbrev-commit
46 Instead of showing the full 40-byte hexadecimal commit object name,
47 show only a partial prefix. Non default number of digits can be
48 specified with "--abbrev=<n>" (which also modifies diff output, if
49 it is displayed).
50 This should make "--pretty=oneline" a whole lot more readable for
52 people using 80-column terminals.
53 --oneline
55 This is a shorthand for "--pretty=oneline --abbrev-commit" used
56 together.
57 --encoding[=<encoding>]
59 The commit objects record the encoding used for the log message in
60 their encoding header; this option can be used to tell the command
61 to re-code the commit log message in the encoding preferred by the
62 user. For non plumbing commands this defaults to UTF-8.
63 --no-notes, --show-notes[=<ref>]
65 Show the notes (see git-notes(1)) that annotate the commit, when
66 showing the commit log message. This is the default for git log,
67 git show and git whatchanged commands when there is no --pretty,
68 --format nor --oneline option is given on the command line.
69 With an optional argument, add this ref to the list of notes. The
71 ref is taken to be in refs/notes/ if it is not qualified.
72 --[no-]standard-notes
74 Enable or disable populating the notes ref list from the
75 core.notesRef and notes.displayRef variables (or corresponding
76 environment overrides). Enabled by default. See git-config(1).
77
79 If the commit is a merge, and if the pretty-format is not oneline,
80 email or raw, an additional line is inserted before the Author: line.
81 This line begins with "Merge: " and the sha1s of ancestral commits are
82 printed, separated by spaces. Note that the listed commits may not
83 necessarily be the list of the direct parent commits if you have
84 limited your view of history: for example, if you are only interested
85 in changes related to a certain directory or file.
86 There are several built-in formats, and you can define additional
88 formats by setting a pretty.<name> config option to either another
89 format name, or a format: string, as described below (see git-
90 config(1)). Here are the details of the built-in formats:
91 · oneline
93 <sha1> <title line>
95 This is designed to be as compact as possible.
97 · short
99 commit <sha1>
101 Author: <author>
102 <title line>
104 · medium
106 commit <sha1>
108 Author: <author>
109 Date: <author date>
110 <title line>
112 <full commit message>
114 · full
116 commit <sha1>
118 Author: <author>
119 Commit: <committer>
120 <title line>
122 <full commit message>
124 · fuller
126 commit <sha1>
128 Author: <author>
129 AuthorDate: <author date>
130 Commit: <committer>
131 CommitDate: <committer date>
132 <title line>
134 <full commit message>
136 · email
138 From <sha1> <date>
140 From: <author>
141 Date: <author date>
142 Subject: [PATCH] <title line>
143 <full commit message>
145 · raw
147 The raw format shows the entire commit exactly as stored in the
149 commit object. Notably, the SHA1s are displayed in full, regardless
150 of whether --abbrev or --no-abbrev are used, and parents
151 information show the true parent commits, without taking grafts nor
152 history simplification into account.
153 · format:<string>
155 The format:<string> format allows you to specify which information
157 you want to show. It works a little bit like printf format, with
158 the notable exception that you get a newline with %n instead of \n.
159 E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
161 would show something like this:
162 The author of fe6e0ee was Junio C Hamano, 23 hours ago
164 The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
165 The placeholders are:
167 · %H: commit hash
169 · %h: abbreviated commit hash
171 · %T: tree hash
173 · %t: abbreviated tree hash
175 · %P: parent hashes
177 · %p: abbreviated parent hashes
179 · %an: author name
181 · %aN: author name (respecting .mailmap, see git-shortlog(1) or
183 git-blame(1))
184 · %ae: author email
186 · %aE: author email (respecting .mailmap, see git-shortlog(1) or
188 git-blame(1))
189 · %ad: author date (format respects --date= option)
191 · %aD: author date, RFC2822 style
193 · %ar: author date, relative
195 · %at: author date, UNIX timestamp
197 · %ai: author date, ISO 8601 format
199 · %cn: committer name
201 · %cN: committer name (respecting .mailmap, see git-shortlog(1)
203 or git-blame(1))
204 · %ce: committer email
206 · %cE: committer email (respecting .mailmap, see git-shortlog(1)
208 or git-blame(1))
209 · %cd: committer date
211 · %cD: committer date, RFC2822 style
213 · %cr: committer date, relative
215 · %ct: committer date, UNIX timestamp
217 · %ci: committer date, ISO 8601 format
219 · %d: ref names, like the --decorate option of git-log(1)
221 · %e: encoding
223 · %s: subject
225 · %f: sanitized subject line, suitable for a filename
227 · %b: body
229 · %B: raw body (unwrapped subject and body)
231 · %N: commit notes
233 · %gD: reflog selector, e.g., refs/stash@{1}
235 · %gd: shortened reflog selector, e.g., stash@{1}
237 · %gs: reflog subject
239 · %Cred: switch color to red
241 · %Cgreen: switch color to green
243 · %Cblue: switch color to blue
245 · %Creset: reset color
247 · %C(...): color specification, as described in color.branch.*
249 config option
250 · %m: left, right or boundary mark
252 · %n: newline
254 · %%: a raw %
256 · %x00: print a byte from a hex code
258 · %w([<w>[,<i1>[,<i2>]]]): switch line wrapping, like the -w
260 option of git-shortlog(1).
261 Note
263 Some placeholders may depend on other options given to the revision
264 traversal engine. For example, the %g* reflog options will insert
265 an empty string unless we are traversing reflog entries (e.g., by
266 git log -g). The %d placeholder will use the "short" decoration
267 format if --decorate was not already provided on the command line.
268 If you add a + (plus sign) after % of a placeholder, a line-feed is
270 inserted immediately before the expansion if and only if the
271 placeholder expands to a non-empty string.
272 If you add a - (minus sign) after % of a placeholder, line-feeds that
274 immediately precede the expansion are deleted if and only if the
275 placeholder expands to an empty string.
276 If you add a ` ` (space) after % of a placeholder, a space is inserted
278 immediately before the expansion if and only if the placeholder expands
279 to a non-empty string.
280 · tformat:
282 The tformat: format works exactly like format:, except that it
284 provides "terminator" semantics instead of "separator" semantics.
285 In other words, each commit has the message terminator character
286 (usually a newline) appended, rather than a separator placed
287 between entries. This means that the final entry of a single-line
288 format will be properly terminated with a new line, just as the
289 "oneline" format does. For example:
290 $ git log -2 --pretty=format:%h 4da45bef \
292 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
293 4da45be
294 7134973 -- NO NEWLINE
295 $ git log -2 --pretty=tformat:%h 4da45bef \
297 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
298 4da45be
299 7134973
300 In addition, any unrecognized string that has a % in it is
302 interpreted as if it has tformat: in front of it. For example,
303 these two are equivalent:
304 $ git log -2 --pretty=tformat:%h 4da45bef
306 $ git log -2 --pretty=%h 4da45bef
307
310 git show v1.0.0
311 Shows the tag v1.0.0, along with the object the tags points at.
312 git show v1.0.0^{tree}
314 Shows the tree pointed to by the tag v1.0.0.
315 git show -s --format=%s v1.0.0^{commit}
317 Shows the subject of the commit pointed to by the tag v1.0.0.
318 git show next~10:Documentation/README
320 Shows the contents of the file Documentation/README as they were
321 current in the 10th last commit of the branch next.
322 git show master:Makefile master:t/Makefile
324 Concatenates the contents of said Makefiles in the head of the
325 branch master.
326
328 At the core level, git is character encoding agnostic.
329 · The pathnames recorded in the index and in the tree objects are
331 treated as uninterpreted sequences of non-NUL bytes. What
332 readdir(2) returns are what are recorded and compared with the data
333 git keeps track of, which in turn are expected to be what lstat(2)
334 and creat(2) accepts. There is no such thing as pathname encoding
335 translation.
336 · The contents of the blob objects are uninterpreted sequences of
338 bytes. There is no encoding translation at the core level.
339 · The commit log messages are uninterpreted sequences of non-NUL
341 bytes.
342 Although we encourage that the commit log messages are encoded in
344 UTF-8, both the core and git Porcelain are designed not to force UTF-8
345 on projects. If all participants of a particular project find it more
346 convenient to use legacy encodings, git does not forbid it. However,
347 there are a few things to keep in mind.
348 1. git commit and git commit-tree issues a warning if the commit log
350 message given to it does not look like a valid UTF-8 string, unless
351 you explicitly say your project uses a legacy encoding. The way to
352 say this is to have i18n.commitencoding in .git/config file, like
353 this:
354 [i18n]
356 commitencoding = ISO-8859-1
357 Commit objects created with the above setting record the value of
359 i18n.commitencoding in its encoding header. This is to help other
360 people who look at them later. Lack of this header implies that the
361 commit log message is encoded in UTF-8.
362 2. git log, git show, git blame and friends look at the encoding
364 header of a commit object, and try to re-code the log message into
365 UTF-8 unless otherwise specified. You can specify the desired
366 output encoding with i18n.logoutputencoding in .git/config file,
367 like this:
368 [i18n]
370 logoutputencoding = ISO-8859-1
371 If you do not have this configuration variable, the value of
373 i18n.commitencoding is used instead.
374 Note that we deliberately chose not to re-code the commit log message
376 when a commit is made to force UTF-8 at the commit object level,
377 because re-coding to UTF-8 is not necessarily a reversible operation.
378
380 Written by Linus Torvalds <torvalds@osdl.org[1]> and Junio C Hamano
381 <gitster@pobox.com[2]>. Significantly enhanced by Johannes Schindelin
382 <Johannes.Schindelin@gmx.de[3]>.
383
385 Documentation by David Greaves, Petr Baudis and the git-list
386 <git@vger.kernel.org[4]>.
387
389 Part of the git(1) suite
390
392 1. torvalds@osdl.org
393 mailto:torvalds@osdl.org
394 2. gitster@pobox.com
396 mailto:gitster@pobox.com
397 3. Johannes.Schindelin@gmx.de
399 mailto:Johannes.Schindelin@gmx.de
400 4. git@vger.kernel.org
402 mailto:git@vger.kernel.org
403Git 1.7.4.4 04/11/2011 GIT-SHOW(1)