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(1) with
20 --name-only).
21 For plain blobs, it shows the plain contents.
23 The command takes options applicable to the git-diff-tree(1) 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 name of the object 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>]
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 --abbrev-commit
42 Instead of showing the full 40-byte hexadecimal commit object name,
43 show only handful hexdigits prefix. Non default number of digits
44 can be specified with "--abbrev=<n>" (which also modifies diff
45 output, if it is displayed).
46 This should make "--pretty=oneline" a whole lot more readable for
48 people using 80-column terminals.
49 --encoding[=<encoding>]
51 The commit objects record the encoding used for the log message in
52 their encoding header; this option can be used to tell the command
53 to re-code the commit log message in the encoding preferred by the
54 user. For non plumbing commands this defaults to UTF-8.
55
57 If the commit is a merge, and if the pretty-format is not oneline,
58 email or raw, an additional line is inserted before the Author: line.
59 This line begins with "Merge: " and the sha1s of ancestral commits are
60 printed, separated by spaces. Note that the listed commits may not
61 necessarily be the list of the direct parent commits if you have
62 limited your view of history: for example, if you are only interested
63 in changes related to a certain directory or file.
64 Here are some additional details for each format:
66 · oneline
69 <sha1> <title line>
72 This is designed to be as compact as possible.
73 · short
75 commit <sha1>
78 Author: <author>
79 <title line>
81 · medium
83 commit <sha1>
86 Author: <author>
87 Date: <date>
88 <title line>
90 <full commit message>
92 · full
94 commit <sha1>
97 Author: <author>
98 Commit: <committer>
99 <title line>
101 <full commit message>
103 · fuller
105 commit <sha1>
108 Author: <author>
109 AuthorDate: <date & time>
110 Commit: <committer>
111 CommitDate: <date & time>
112 <title line>
114 <full commit message>
116 · email
118 From <sha1> <date>
121 From: <author>
122 Date: <date & time>
123 Subject: [PATCH] <title line>
124 <full commit message>
126 · raw
128 The raw format shows the entire commit exactly as stored in the
130 commit object. Notably, the SHA1s are displayed in full, regardless
131 of whether --abbrev or --no-abbrev are used, and parents
132 information show the true parent commits, without taking grafts nor
133 history simplification into account.
134 · format:
136 The format: format allows you to specify which information you want
138 to show. It works a little bit like printf format, with the notable
139 exception that you get a newline with %n instead of \n.
140 E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
142 would show something like this:
143 The author of fe6e0ee was Junio C Hamano, 23 hours ago
147 The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
148 The placeholders are:
151 · %H: commit hash
154 · %h: abbreviated commit hash
156 · %T: tree hash
158 · %t: abbreviated tree hash
160 · %P: parent hashes
162 · %p: abbreviated parent hashes
164 · %an: author name
166 · %ae: author email
168 · %ad: author date
170 · %aD: author date, RFC2822 style
172 · %ar: author date, relative
174 · %at: author date, UNIX timestamp
176 · %ai: author date, ISO 8601 format
178 · %cn: committer name
180 · %ce: committer email
182 · %cd: committer date
184 · %cD: committer date, RFC2822 style
186 · %cr: committer date, relative
188 · %ct: committer date, UNIX timestamp
190 · %ci: committer date, ISO 8601 format
192 · %e: encoding
194 · %s: subject
196 · %b: body
198 · %Cred: switch color to red
200 · %Cgreen: switch color to green
202 · %Cblue: switch color to blue
204 · %Creset: reset color
206 · %m: left, right or boundary mark
208 · %n: newline
210
212 git show v1.0.0
213 Shows the tag v1.0.0, along with the object the tags points at.
214 git show v1.0.0^{tree}
216 Shows the tree pointed to by the tag v1.0.0.
217 git show next~10:Documentation/README
219 Shows the contents of the file Documentation/README as they were
220 current in the 10th last commit of the branch next.
221 git show master:Makefile master:t/Makefile
223 Concatenates the contents of said Makefiles in the head of the
224 branch master.
225
227 At the core level, git is character encoding agnostic.
228 · The pathnames recorded in the index and in the tree objects are
231 treated as uninterpreted sequences of non-NUL bytes. What
232 readdir(2) returns are what are recorded and compared with the data
233 git keeps track of, which in turn are expected to be what lstat(2)
234 and creat(2) accepts. There is no such thing as pathname encoding
235 translation.
236 · The contents of the blob objects are uninterpreted sequence of
238 bytes. There is no encoding translation at the core level.
239 · The commit log messages are uninterpreted sequence of non-NUL
241 bytes.
242 Although we encourage that the commit log messages are encoded in
243 UTF-8, both the core and git Porcelain are designed not to force UTF-8
244 on projects. If all participants of a particular project find it more
245 convenient to use legacy encodings, git does not forbid it. However,
246 there are a few things to keep in mind.
247 1. git-commit-tree (hence, git-commit which uses it) issues an
250 warning if the commit log message given to it does not look like a
251 valid UTF-8 string, unless you explicitly say your project uses a
252 legacy encoding. The way to say this is to have i18n.commitencoding
253 in .git/config file, like this:
254 [i18n]
258 commitencoding = ISO-8859-1
259 Commit objects created with the above setting record the value of
261 i18n.commitencoding in its encoding header. This is to help other
262 people who look at them later. Lack of this header implies that the
263 commit log message is encoded in UTF-8.
264 2. git-log, git-show and friends looks at the encoding header of a
266 commit object, and tries to re-code the log message into UTF-8
267 unless otherwise specified. You can specify the desired output
268 encoding with i18n.logoutputencoding in .git/config file, like
269 this:
270 [i18n]
274 logoutputencoding = ISO-8859-1
275 If you do not have this configuration variable, the value of
277 i18n.commitencoding is used instead.
278 Note that we deliberately chose not to re-code the commit log message
279 when a commit is made to force UTF-8 at the commit object level,
280 because re-coding to UTF-8 is not necessarily a reversible operation.
281
283 Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano
284 <junkio@cox.net>. Significantly enhanced by Johannes Schindelin
285 <Johannes.Schindelin@gmx.de>.
286
288 Documentation by David Greaves, Petr Baudis and the git-list
289 <git@vger.kernel.org>.
290 This manual page is a stub. You can help the git documentation by
292 expanding it.
293
295 Part of the git(7) suite
296Git 1.5.3.3 10/09/2007 GIT-SHOW(1)