1GIT-SHOW(1)                       Git Manual                       GIT-SHOW(1)
2
3
4

NAME

6       git-show - Show various types of objects
7

SYNOPSIS

9       git show [options] <object>...
10
11

DESCRIPTION

13       Shows one or more objects (blobs, trees, tags and commits).
14
15       For commits it shows the log message and textual diff. It also presents
16       the merge commit in a special format as produced by git diff-tree --cc.
17
18       For tags, it shows the tag message and the referenced objects.
19
20       For trees, it shows the names (equivalent to git ls-tree with
21       --name-only).
22
23       For plain blobs, it shows the plain contents.
24
25       The command takes options applicable to the git diff-tree command to
26       control how the changes the commit introduces are shown.
27
28       This manual page describes only the most frequently used options.
29

OPTIONS

31       <object>...
32           The names of objects to show. For a more complete list of ways to
33           spell object names, see "SPECIFYING REVISIONS" section in
34           gitrevisions(7).
35
36       --pretty[=<format>], --format=<format>
37           Pretty-print the contents of the commit logs in a given format,
38           where <format> can be one of oneline, short, medium, full, fuller,
39           email, raw and format:<string>. See the "PRETTY FORMATS" section
40           for some additional details for each format. When omitted, the
41           format defaults to medium.
42
43           Note: you can specify the default pretty format in the repository
44           configuration (see git-config(1)).
45
46       --abbrev-commit
47           Instead of showing the full 40-byte hexadecimal commit object name,
48           show only a partial prefix. Non default number of digits can be
49           specified with "--abbrev=<n>" (which also modifies diff output, if
50           it is displayed).
51
52           This should make "--pretty=oneline" a whole lot more readable for
53           people using 80-column terminals.
54
55       --no-abbrev-commit
56           Show the full 40-byte hexadecimal commit object name. This negates
57           --abbrev-commit and those options which imply it such as
58           "--oneline". It also overrides the log.abbrevCommit variable.
59
60       --oneline
61           This is a shorthand for "--pretty=oneline --abbrev-commit" used
62           together.
63
64       --encoding[=<encoding>]
65           The commit objects record the encoding used for the log message in
66           their encoding header; this option can be used to tell the command
67           to re-code the commit log message in the encoding preferred by the
68           user. For non plumbing commands this defaults to UTF-8.
69
70       --notes[=<ref>]
71           Show the notes (see git-notes(1)) that annotate the commit, when
72           showing the commit log message. This is the default for git log,
73           git show and git whatchanged commands when there is no --pretty,
74           --format nor --oneline option given on the command line.
75
76           By default, the notes shown are from the notes refs listed in the
77           core.notesRef and notes.displayRef variables (or corresponding
78           environment overrides). See git-config(1) for more details.
79
80           With an optional <ref> argument, show this notes ref instead of the
81           default notes ref(s). The ref is taken to be in refs/notes/ if it
82           is not qualified.
83
84           Multiple --notes options can be combined to control which notes are
85           being displayed. Examples: "--notes=foo" will show only notes from
86           "refs/notes/foo"; "--notes=foo --notes" will show both notes from
87           "refs/notes/foo" and from the default notes ref(s).
88
89       --no-notes
90           Do not show notes. This negates the above --notes option, by
91           resetting the list of notes refs from which notes are shown.
92           Options are parsed in the order given on the command line, so e.g.
93           "--notes --notes=foo --no-notes --notes=bar" will only show notes
94           from "refs/notes/bar".
95
96       --show-notes[=<ref>], --[no-]standard-notes
97           These options are deprecated. Use the above --notes/--no-notes
98           options instead.
99
100       --show-signature
101           Check the validity of a signed commit object by passing the
102           signature to gpg --verify and show the output.
103

PRETTY FORMATS

105       If the commit is a merge, and if the pretty-format is not oneline,
106       email or raw, an additional line is inserted before the Author: line.
107       This line begins with "Merge: " and the sha1s of ancestral commits are
108       printed, separated by spaces. Note that the listed commits may not
109       necessarily be the list of the direct parent commits if you have
110       limited your view of history: for example, if you are only interested
111       in changes related to a certain directory or file.
112
113       There are several built-in formats, and you can define additional
114       formats by setting a pretty.<name> config option to either another
115       format name, or a format: string, as described below (see git-
116       config(1)). Here are the details of the built-in formats:
117
118       ·   oneline
119
120               <sha1> <title line>
121
122           This is designed to be as compact as possible.
123
124       ·   short
125
126               commit <sha1>
127               Author: <author>
128
129               <title line>
130
131       ·   medium
132
133               commit <sha1>
134               Author: <author>
135               Date:   <author date>
136
137               <title line>
138
139               <full commit message>
140
141       ·   full
142
143               commit <sha1>
144               Author: <author>
145               Commit: <committer>
146
147               <title line>
148
149               <full commit message>
150
151       ·   fuller
152
153               commit <sha1>
154               Author:     <author>
155               AuthorDate: <author date>
156               Commit:     <committer>
157               CommitDate: <committer date>
158
159               <title line>
160
161               <full commit message>
162
163       ·   email
164
165               From <sha1> <date>
166               From: <author>
167               Date: <author date>
168               Subject: [PATCH] <title line>
169
170               <full commit message>
171
172       ·   raw
173
174           The raw format shows the entire commit exactly as stored in the
175           commit object. Notably, the SHA-1s are displayed in full,
176           regardless of whether --abbrev or --no-abbrev are used, and parents
177           information show the true parent commits, without taking grafts nor
178           history simplification into account.
179
180       ·   format:<string>
181
182           The format:<string> format allows you to specify which information
183           you want to show. It works a little bit like printf format, with
184           the notable exception that you get a newline with %n instead of \n.
185
186           E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
187           would show something like this:
188
189               The author of fe6e0ee was Junio C Hamano, 23 hours ago
190               The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
191
192           The placeholders are:
193
194           ·   %H: commit hash
195
196           ·   %h: abbreviated commit hash
197
198           ·   %T: tree hash
199
200           ·   %t: abbreviated tree hash
201
202           ·   %P: parent hashes
203
204           ·   %p: abbreviated parent hashes
205
206           ·   %an: author name
207
208           ·   %aN: author name (respecting .mailmap, see git-shortlog(1) or
209               git-blame(1))
210
211           ·   %ae: author email
212
213           ·   %aE: author email (respecting .mailmap, see git-shortlog(1) or
214               git-blame(1))
215
216           ·   %ad: author date (format respects --date= option)
217
218           ·   %aD: author date, RFC2822 style
219
220           ·   %ar: author date, relative
221
222           ·   %at: author date, UNIX timestamp
223
224           ·   %ai: author date, ISO 8601 format
225
226           ·   %cn: committer name
227
228           ·   %cN: committer name (respecting .mailmap, see git-shortlog(1)
229               or git-blame(1))
230
231           ·   %ce: committer email
232
233           ·   %cE: committer email (respecting .mailmap, see git-shortlog(1)
234               or git-blame(1))
235
236           ·   %cd: committer date
237
238           ·   %cD: committer date, RFC2822 style
239
240           ·   %cr: committer date, relative
241
242           ·   %ct: committer date, UNIX timestamp
243
244           ·   %ci: committer date, ISO 8601 format
245
246           ·   %d: ref names, like the --decorate option of git-log(1)
247
248           ·   %e: encoding
249
250           ·   %s: subject
251
252           ·   %f: sanitized subject line, suitable for a filename
253
254           ·   %b: body
255
256           ·   %B: raw body (unwrapped subject and body)
257
258           ·   %N: commit notes
259
260           ·   %GG: raw verification message from GPG for a signed commit
261
262           ·   %G?: show "G" for a Good signature, "B" for a Bad signature,
263               "U" for a good, untrusted signature and "N" for no signature
264
265           ·   %GS: show the name of the signer for a signed commit
266
267           ·   %GK: show the key used to sign a signed commit
268
269           ·   %gD: reflog selector, e.g., refs/stash@{1}
270
271           ·   %gd: shortened reflog selector, e.g., stash@{1}
272
273           ·   %gn: reflog identity name
274
275           ·   %gN: reflog identity name (respecting .mailmap, see git-
276               shortlog(1) or git-blame(1))
277
278           ·   %ge: reflog identity email
279
280           ·   %gE: reflog identity email (respecting .mailmap, see git-
281               shortlog(1) or git-blame(1))
282
283           ·   %gs: reflog subject
284
285           ·   %Cred: switch color to red
286
287           ·   %Cgreen: switch color to green
288
289           ·   %Cblue: switch color to blue
290
291           ·   %Creset: reset color
292
293           ·   %C(...): color specification, as described in color.branch.*
294               config option; adding auto, at the beginning will emit color
295               only when colors are enabled for log output (by color.diff,
296               color.ui, or --color, and respecting the auto settings of the
297               former if we are going to a terminal).  auto alone (i.e.
298               %C(auto)) will turn on auto coloring on the next placeholders
299               until the color is switched again.
300
301           ·   %m: left, right or boundary mark
302
303           ·   %n: newline
304
305           ·   %%: a raw %
306
307           ·   %x00: print a byte from a hex code
308
309           ·   %w([<w>[,<i1>[,<i2>]]]): switch line wrapping, like the -w
310               option of git-shortlog(1).
311
312           ·   %<(<N>[,trunc|ltrunc|mtrunc]): make the next placeholder take
313               at least N columns, padding spaces on the right if necessary.
314               Optionally truncate at the beginning (ltrunc), the middle
315               (mtrunc) or the end (trunc) if the output is longer than N
316               columns. Note that truncating only works correctly with N >= 2.
317
318           ·   %<|(<N>): make the next placeholder take at least until Nth
319               columns, padding spaces on the right if necessary
320
321           ·   %>(<N>), %>|(<N>): similar to %<(<N>), %<|(<N>) respectively,
322               but padding spaces on the left
323
324           ·   %>>(<N>), %>>|(<N>): similar to %>(<N>), %>|(<N>) respectively,
325               except that if the next placeholder takes more spaces than
326               given and there are spaces on its left, use those spaces
327
328           ·   %><(<N>), %><|(<N>): similar to % <(<N>), %<|(<N>)
329               respectively, but padding both sides (i.e. the text is
330               centered)
331
332           Note
333           Some placeholders may depend on other options given to the revision
334           traversal engine. For example, the %g* reflog options will insert
335           an empty string unless we are traversing reflog entries (e.g., by
336           git log -g). The %d placeholder will use the "short" decoration
337           format if --decorate was not already provided on the command line.
338
339       If you add a + (plus sign) after % of a placeholder, a line-feed is
340       inserted immediately before the expansion if and only if the
341       placeholder expands to a non-empty string.
342
343       If you add a - (minus sign) after % of a placeholder, line-feeds that
344       immediately precede the expansion are deleted if and only if the
345       placeholder expands to an empty string.
346
347       If you add a ` ` (space) after % of a placeholder, a space is inserted
348       immediately before the expansion if and only if the placeholder expands
349       to a non-empty string.
350
351       ·   tformat:
352
353           The tformat: format works exactly like format:, except that it
354           provides "terminator" semantics instead of "separator" semantics.
355           In other words, each commit has the message terminator character
356           (usually a newline) appended, rather than a separator placed
357           between entries. This means that the final entry of a single-line
358           format will be properly terminated with a new line, just as the
359           "oneline" format does. For example:
360
361               $ git log -2 --pretty=format:%h 4da45bef \
362                 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
363               4da45be
364               7134973 -- NO NEWLINE
365
366               $ git log -2 --pretty=tformat:%h 4da45bef \
367                 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
368               4da45be
369               7134973
370
371           In addition, any unrecognized string that has a % in it is
372           interpreted as if it has tformat: in front of it. For example,
373           these two are equivalent:
374
375               $ git log -2 --pretty=tformat:%h 4da45bef
376               $ git log -2 --pretty=%h 4da45bef
377
378

EXAMPLES

380       git show v1.0.0
381           Shows the tag v1.0.0, along with the object the tags points at.
382
383       git show v1.0.0^{tree}
384           Shows the tree pointed to by the tag v1.0.0.
385
386       git show -s --format=%s v1.0.0^{commit}
387           Shows the subject of the commit pointed to by the tag v1.0.0.
388
389       git show next~10:Documentation/README
390           Shows the contents of the file Documentation/README as they were
391           current in the 10th last commit of the branch next.
392
393       git show master:Makefile master:t/Makefile
394           Concatenates the contents of said Makefiles in the head of the
395           branch master.
396

DISCUSSION

398       At the core level, Git is character encoding agnostic.
399
400       ·   The pathnames recorded in the index and in the tree objects are
401           treated as uninterpreted sequences of non-NUL bytes. What
402           readdir(2) returns are what are recorded and compared with the data
403           Git keeps track of, which in turn are expected to be what lstat(2)
404           and creat(2) accepts. There is no such thing as pathname encoding
405           translation.
406
407       ·   The contents of the blob objects are uninterpreted sequences of
408           bytes. There is no encoding translation at the core level.
409
410       ·   The commit log messages are uninterpreted sequences of non-NUL
411           bytes.
412
413       Although we encourage that the commit log messages are encoded in
414       UTF-8, both the core and Git Porcelain are designed not to force UTF-8
415       on projects. If all participants of a particular project find it more
416       convenient to use legacy encodings, Git does not forbid it. However,
417       there are a few things to keep in mind.
418
419        1. git commit and git commit-tree issues a warning if the commit log
420           message given to it does not look like a valid UTF-8 string, unless
421           you explicitly say your project uses a legacy encoding. The way to
422           say this is to have i18n.commitencoding in .git/config file, like
423           this:
424
425               [i18n]
426                       commitencoding = ISO-8859-1
427
428           Commit objects created with the above setting record the value of
429           i18n.commitencoding in its encoding header. This is to help other
430           people who look at them later. Lack of this header implies that the
431           commit log message is encoded in UTF-8.
432
433        2. git log, git show, git blame and friends look at the encoding
434           header of a commit object, and try to re-code the log message into
435           UTF-8 unless otherwise specified. You can specify the desired
436           output encoding with i18n.logoutputencoding in .git/config file,
437           like this:
438
439               [i18n]
440                       logoutputencoding = ISO-8859-1
441
442           If you do not have this configuration variable, the value of
443           i18n.commitencoding is used instead.
444
445       Note that we deliberately chose not to re-code the commit log message
446       when a commit is made to force UTF-8 at the commit object level,
447       because re-coding to UTF-8 is not necessarily a reversible operation.
448

GIT

450       Part of the git(1) suite
451
452
453
454Git 1.8.3.1                       11/19/2018                       GIT-SHOW(1)
Impressum