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 (defaults to HEAD). For a more
33           complete list of ways to spell object names, see "SPECIFYING
34           REVISIONS" section in 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, format:<string> and tformat:<string>. When <format> is
40           none of the above, and has %placeholder in it, it acts as if
41           --pretty=tformat:<format> were given.
42
43           See the "PRETTY FORMATS" section for some additional details for
44           each format. When =<format> part is omitted, it defaults to medium.
45
46           Note: you can specify the default pretty format in the repository
47           configuration (see git-config(1)).
48
49       --abbrev-commit
50           Instead of showing the full 40-byte hexadecimal commit object name,
51           show only a partial prefix. Non default number of digits can be
52           specified with "--abbrev=<n>" (which also modifies diff output, if
53           it is displayed).
54
55           This should make "--pretty=oneline" a whole lot more readable for
56           people using 80-column terminals.
57
58       --no-abbrev-commit
59           Show the full 40-byte hexadecimal commit object name. This negates
60           --abbrev-commit and those options which imply it such as
61           "--oneline". It also overrides the log.abbrevCommit variable.
62
63       --oneline
64           This is a shorthand for "--pretty=oneline --abbrev-commit" used
65           together.
66
67       --encoding=<encoding>
68           The commit objects record the encoding used for the log message in
69           their encoding header; this option can be used to tell the command
70           to re-code the commit log message in the encoding preferred by the
71           user. For non plumbing commands this defaults to UTF-8. Note that
72           if an object claims to be encoded in X and we are outputting in X,
73           we will output the object verbatim; this means that invalid
74           sequences in the original commit may be copied to the output.
75
76       --expand-tabs=<n>, --expand-tabs, --no-expand-tabs
77           Perform a tab expansion (replace each tab with enough spaces to
78           fill to the next display column that is multiple of <n>) in the log
79           message before showing it in the output.  --expand-tabs is a
80           short-hand for --expand-tabs=8, and --no-expand-tabs is a
81           short-hand for --expand-tabs=0, which disables tab expansion.
82
83           By default, tabs are expanded in pretty formats that indent the log
84           message by 4 spaces (i.e.  medium, which is the default, full, and
85           fuller).
86
87       --notes[=<treeish>]
88           Show the notes (see git-notes(1)) that annotate the commit, when
89           showing the commit log message. This is the default for git log,
90           git show and git whatchanged commands when there is no --pretty,
91           --format, or --oneline option given on the command line.
92
93           By default, the notes shown are from the notes refs listed in the
94           core.notesRef and notes.displayRef variables (or corresponding
95           environment overrides). See git-config(1) for more details.
96
97           With an optional <treeish> argument, use the treeish to find the
98           notes to display. The treeish can specify the full refname when it
99           begins with refs/notes/; when it begins with notes/, refs/ and
100           otherwise refs/notes/ is prefixed to form a full name of the ref.
101
102           Multiple --notes options can be combined to control which notes are
103           being displayed. Examples: "--notes=foo" will show only notes from
104           "refs/notes/foo"; "--notes=foo --notes" will show both notes from
105           "refs/notes/foo" and from the default notes ref(s).
106
107       --no-notes
108           Do not show notes. This negates the above --notes option, by
109           resetting the list of notes refs from which notes are shown.
110           Options are parsed in the order given on the command line, so e.g.
111           "--notes --notes=foo --no-notes --notes=bar" will only show notes
112           from "refs/notes/bar".
113
114       --show-notes[=<treeish>], --[no-]standard-notes
115           These options are deprecated. Use the above --notes/--no-notes
116           options instead.
117
118       --show-signature
119           Check the validity of a signed commit object by passing the
120           signature to gpg --verify and show the output.
121

PRETTY FORMATS

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

COMMON DIFF OPTIONS

437       -p, -u, --patch
438           Generate patch (see section on generating patches).
439
440       -s, --no-patch
441           Suppress diff output. Useful for commands like git show that show
442           the patch by default, or to cancel the effect of --patch.
443
444       -U<n>, --unified=<n>
445           Generate diffs with <n> lines of context instead of the usual
446           three. Implies -p.
447
448       --raw
449           For each commit, show a summary of changes using the raw diff
450           format. See the "RAW OUTPUT FORMAT" section of git-diff(1). This is
451           different from showing the log itself in raw format, which you can
452           achieve with --format=raw.
453
454       --patch-with-raw
455           Synonym for -p --raw.
456
457       --indent-heuristic
458           Enable the heuristic that shifts diff hunk boundaries to make
459           patches easier to read. This is the default.
460
461       --no-indent-heuristic
462           Disable the indent heuristic.
463
464       --minimal
465           Spend extra time to make sure the smallest possible diff is
466           produced.
467
468       --patience
469           Generate a diff using the "patience diff" algorithm.
470
471       --histogram
472           Generate a diff using the "histogram diff" algorithm.
473
474       --anchored=<text>
475           Generate a diff using the "anchored diff" algorithm.
476
477           This option may be specified more than once.
478
479           If a line exists in both the source and destination, exists only
480           once, and starts with this text, this algorithm attempts to prevent
481           it from appearing as a deletion or addition in the output. It uses
482           the "patience diff" algorithm internally.
483
484       --diff-algorithm={patience|minimal|histogram|myers}
485           Choose a diff algorithm. The variants are as follows:
486
487           default, myers
488               The basic greedy diff algorithm. Currently, this is the
489               default.
490
491           minimal
492               Spend extra time to make sure the smallest possible diff is
493               produced.
494
495           patience
496               Use "patience diff" algorithm when generating patches.
497
498           histogram
499               This algorithm extends the patience algorithm to "support
500               low-occurrence common elements".
501
502           For instance, if you configured the diff.algorithm variable to a
503           non-default value and want to use the default one, then you have to
504           use --diff-algorithm=default option.
505
506       --stat[=<width>[,<name-width>[,<count>]]]
507           Generate a diffstat. By default, as much space as necessary will be
508           used for the filename part, and the rest for the graph part.
509           Maximum width defaults to terminal width, or 80 columns if not
510           connected to a terminal, and can be overridden by <width>. The
511           width of the filename part can be limited by giving another width
512           <name-width> after a comma. The width of the graph part can be
513           limited by using --stat-graph-width=<width> (affects all commands
514           generating a stat graph) or by setting diff.statGraphWidth=<width>
515           (does not affect git format-patch). By giving a third parameter
516           <count>, you can limit the output to the first <count> lines,
517           followed by ...  if there are more.
518
519           These parameters can also be set individually with
520           --stat-width=<width>, --stat-name-width=<name-width> and
521           --stat-count=<count>.
522
523       --compact-summary
524           Output a condensed summary of extended header information such as
525           file creations or deletions ("new" or "gone", optionally "+l" if
526           it’s a symlink) and mode changes ("+x" or "-x" for adding or
527           removing executable bit respectively) in diffstat. The information
528           is put between the filename part and the graph part. Implies
529           --stat.
530
531       --numstat
532           Similar to --stat, but shows number of added and deleted lines in
533           decimal notation and pathname without abbreviation, to make it more
534           machine friendly. For binary files, outputs two - instead of saying
535           0 0.
536
537       --shortstat
538           Output only the last line of the --stat format containing total
539           number of modified files, as well as number of added and deleted
540           lines.
541
542       --dirstat[=<param1,param2,...>]
543           Output the distribution of relative amount of changes for each
544           sub-directory. The behavior of --dirstat can be customized by
545           passing it a comma separated list of parameters. The defaults are
546           controlled by the diff.dirstat configuration variable (see git-
547           config(1)). The following parameters are available:
548
549           changes
550               Compute the dirstat numbers by counting the lines that have
551               been removed from the source, or added to the destination. This
552               ignores the amount of pure code movements within a file. In
553               other words, rearranging lines in a file is not counted as much
554               as other changes. This is the default behavior when no
555               parameter is given.
556
557           lines
558               Compute the dirstat numbers by doing the regular line-based
559               diff analysis, and summing the removed/added line counts. (For
560               binary files, count 64-byte chunks instead, since binary files
561               have no natural concept of lines). This is a more expensive
562               --dirstat behavior than the changes behavior, but it does count
563               rearranged lines within a file as much as other changes. The
564               resulting output is consistent with what you get from the other
565               --*stat options.
566
567           files
568               Compute the dirstat numbers by counting the number of files
569               changed. Each changed file counts equally in the dirstat
570               analysis. This is the computationally cheapest --dirstat
571               behavior, since it does not have to look at the file contents
572               at all.
573
574           cumulative
575               Count changes in a child directory for the parent directory as
576               well. Note that when using cumulative, the sum of the
577               percentages reported may exceed 100%. The default
578               (non-cumulative) behavior can be specified with the
579               noncumulative parameter.
580
581           <limit>
582               An integer parameter specifies a cut-off percent (3% by
583               default). Directories contributing less than this percentage of
584               the changes are not shown in the output.
585
586           Example: The following will count changed files, while ignoring
587           directories with less than 10% of the total amount of changed
588           files, and accumulating child directory counts in the parent
589           directories: --dirstat=files,10,cumulative.
590
591       --summary
592           Output a condensed summary of extended header information such as
593           creations, renames and mode changes.
594
595       --patch-with-stat
596           Synonym for -p --stat.
597
598       -z
599           Separate the commits with NULs instead of with new newlines.
600
601           Also, when --raw or --numstat has been given, do not munge
602           pathnames and use NULs as output field terminators.
603
604           Without this option, pathnames with "unusual" characters are quoted
605           as explained for the configuration variable core.quotePath (see
606           git-config(1)).
607
608       --name-only
609           Show only names of changed files.
610
611       --name-status
612           Show only names and status of changed files. See the description of
613           the --diff-filter option on what the status letters mean.
614
615       --submodule[=<format>]
616           Specify how differences in submodules are shown. When specifying
617           --submodule=short the short format is used. This format just shows
618           the names of the commits at the beginning and end of the range.
619           When --submodule or --submodule=log is specified, the log format is
620           used. This format lists the commits in the range like git-
621           submodule(1) summary does. When --submodule=diff is specified, the
622           diff format is used. This format shows an inline diff of the
623           changes in the submodule contents between the commit range.
624           Defaults to diff.submodule or the short format if the config option
625           is unset.
626
627       --color[=<when>]
628           Show colored diff.  --color (i.e. without =<when>) is the same as
629           --color=always.  <when> can be one of always, never, or auto.
630
631       --no-color
632           Turn off colored diff. It is the same as --color=never.
633
634       --color-moved[=<mode>]
635           Moved lines of code are colored differently. The <mode> defaults to
636           no if the option is not given and to zebra if the option with no
637           mode is given. The mode must be one of:
638
639           no
640               Moved lines are not highlighted.
641
642           default
643               Is a synonym for zebra. This may change to a more sensible mode
644               in the future.
645
646           plain
647               Any line that is added in one location and was removed in
648               another location will be colored with color.diff.newMoved.
649               Similarly color.diff.oldMoved will be used for removed lines
650               that are added somewhere else in the diff. This mode picks up
651               any moved line, but it is not very useful in a review to
652               determine if a block of code was moved without permutation.
653
654           blocks
655               Blocks of moved text of at least 20 alphanumeric characters are
656               detected greedily. The detected blocks are painted using either
657               the color.diff.{old,new}Moved color. Adjacent blocks cannot be
658               told apart.
659
660           zebra
661               Blocks of moved text are detected as in blocks mode. The blocks
662               are painted using either the color.diff.{old,new}Moved color or
663               color.diff.{old,new}MovedAlternative. The change between the
664               two colors indicates that a new block was detected.
665
666           dimmed-zebra
667               Similar to zebra, but additional dimming of uninteresting parts
668               of moved code is performed. The bordering lines of two adjacent
669               blocks are considered interesting, the rest is uninteresting.
670               dimmed_zebra is a deprecated synonym.
671
672       --color-moved-ws=<modes>
673           This configures how white spaces are ignored when performing the
674           move detection for --color-moved. These modes can be given as a
675           comma separated list:
676
677           ignore-space-at-eol
678               Ignore changes in whitespace at EOL.
679
680           ignore-space-change
681               Ignore changes in amount of whitespace. This ignores whitespace
682               at line end, and considers all other sequences of one or more
683               whitespace characters to be equivalent.
684
685           ignore-all-space
686               Ignore whitespace when comparing lines. This ignores
687               differences even if one line has whitespace where the other
688               line has none.
689
690           allow-indentation-change
691               Initially ignore any white spaces in the move detection, then
692               group the moved code blocks only into a block if the change in
693               whitespace is the same per line. This is incompatible with the
694               other modes.
695
696       --word-diff[=<mode>]
697           Show a word diff, using the <mode> to delimit changed words. By
698           default, words are delimited by whitespace; see --word-diff-regex
699           below. The <mode> defaults to plain, and must be one of:
700
701           color
702               Highlight changed words using only colors. Implies --color.
703
704           plain
705               Show words as [-removed-] and {+added+}. Makes no attempts to
706               escape the delimiters if they appear in the input, so the
707               output may be ambiguous.
708
709           porcelain
710               Use a special line-based format intended for script
711               consumption. Added/removed/unchanged runs are printed in the
712               usual unified diff format, starting with a +/-/` ` character at
713               the beginning of the line and extending to the end of the line.
714               Newlines in the input are represented by a tilde ~ on a line of
715               its own.
716
717           none
718               Disable word diff again.
719
720           Note that despite the name of the first mode, color is used to
721           highlight the changed parts in all modes if enabled.
722
723       --word-diff-regex=<regex>
724           Use <regex> to decide what a word is, instead of considering runs
725           of non-whitespace to be a word. Also implies --word-diff unless it
726           was already enabled.
727
728           Every non-overlapping match of the <regex> is considered a word.
729           Anything between these matches is considered whitespace and
730           ignored(!) for the purposes of finding differences. You may want to
731           append |[^[:space:]] to your regular expression to make sure that
732           it matches all non-whitespace characters. A match that contains a
733           newline is silently truncated(!) at the newline.
734
735           For example, --word-diff-regex=.  will treat each character as a
736           word and, correspondingly, show differences character by character.
737
738           The regex can also be set via a diff driver or configuration
739           option, see gitattributes(5) or git-config(1). Giving it explicitly
740           overrides any diff driver or configuration setting. Diff drivers
741           override configuration settings.
742
743       --color-words[=<regex>]
744           Equivalent to --word-diff=color plus (if a regex was specified)
745           --word-diff-regex=<regex>.
746
747       --no-renames
748           Turn off rename detection, even when the configuration file gives
749           the default to do so.
750
751       --check
752           Warn if changes introduce conflict markers or whitespace errors.
753           What are considered whitespace errors is controlled by
754           core.whitespace configuration. By default, trailing whitespaces
755           (including lines that consist solely of whitespaces) and a space
756           character that is immediately followed by a tab character inside
757           the initial indent of the line are considered whitespace errors.
758           Exits with non-zero status if problems are found. Not compatible
759           with --exit-code.
760
761       --ws-error-highlight=<kind>
762           Highlight whitespace errors in the context, old or new lines of the
763           diff. Multiple values are separated by comma, none resets previous
764           values, default reset the list to new and all is a shorthand for
765           old,new,context. When this option is not given, and the
766           configuration variable diff.wsErrorHighlight is not set, only
767           whitespace errors in new lines are highlighted. The whitespace
768           errors are colored with color.diff.whitespace.
769
770       --full-index
771           Instead of the first handful of characters, show the full pre- and
772           post-image blob object names on the "index" line when generating
773           patch format output.
774
775       --binary
776           In addition to --full-index, output a binary diff that can be
777           applied with git-apply.
778
779       --abbrev[=<n>]
780           Instead of showing the full 40-byte hexadecimal object name in
781           diff-raw format output and diff-tree header lines, show only a
782           partial prefix. This is independent of the --full-index option
783           above, which controls the diff-patch output format. Non default
784           number of digits can be specified with --abbrev=<n>.
785
786       -B[<n>][/<m>], --break-rewrites[=[<n>][/<m>]]
787           Break complete rewrite changes into pairs of delete and create.
788           This serves two purposes:
789
790           It affects the way a change that amounts to a total rewrite of a
791           file not as a series of deletion and insertion mixed together with
792           a very few lines that happen to match textually as the context, but
793           as a single deletion of everything old followed by a single
794           insertion of everything new, and the number m controls this aspect
795           of the -B option (defaults to 60%).  -B/70% specifies that less
796           than 30% of the original should remain in the result for Git to
797           consider it a total rewrite (i.e. otherwise the resulting patch
798           will be a series of deletion and insertion mixed together with
799           context lines).
800
801           When used with -M, a totally-rewritten file is also considered as
802           the source of a rename (usually -M only considers a file that
803           disappeared as the source of a rename), and the number n controls
804           this aspect of the -B option (defaults to 50%).  -B20% specifies
805           that a change with addition and deletion compared to 20% or more of
806           the file’s size are eligible for being picked up as a possible
807           source of a rename to another file.
808
809       -M[<n>], --find-renames[=<n>]
810           If generating diffs, detect and report renames for each commit. For
811           following files across renames while traversing history, see
812           --follow. If n is specified, it is a threshold on the similarity
813           index (i.e. amount of addition/deletions compared to the file’s
814           size). For example, -M90% means Git should consider a delete/add
815           pair to be a rename if more than 90% of the file hasn’t changed.
816           Without a % sign, the number is to be read as a fraction, with a
817           decimal point before it. I.e., -M5 becomes 0.5, and is thus the
818           same as -M50%. Similarly, -M05 is the same as -M5%. To limit
819           detection to exact renames, use -M100%. The default similarity
820           index is 50%.
821
822       -C[<n>], --find-copies[=<n>]
823           Detect copies as well as renames. See also --find-copies-harder. If
824           n is specified, it has the same meaning as for -M<n>.
825
826       --find-copies-harder
827           For performance reasons, by default, -C option finds copies only if
828           the original file of the copy was modified in the same changeset.
829           This flag makes the command inspect unmodified files as candidates
830           for the source of copy. This is a very expensive operation for
831           large projects, so use it with caution. Giving more than one -C
832           option has the same effect.
833
834       -D, --irreversible-delete
835           Omit the preimage for deletes, i.e. print only the header but not
836           the diff between the preimage and /dev/null. The resulting patch is
837           not meant to be applied with patch or git apply; this is solely for
838           people who want to just concentrate on reviewing the text after the
839           change. In addition, the output obviously lacks enough information
840           to apply such a patch in reverse, even manually, hence the name of
841           the option.
842
843           When used together with -B, omit also the preimage in the deletion
844           part of a delete/create pair.
845
846       -l<num>
847           The -M and -C options require O(n^2) processing time where n is the
848           number of potential rename/copy targets. This option prevents
849           rename/copy detection from running if the number of rename/copy
850           targets exceeds the specified number.
851
852       --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
853           Select only files that are Added (A), Copied (C), Deleted (D),
854           Modified (M), Renamed (R), have their type (i.e. regular file,
855           symlink, submodule, ...) changed (T), are Unmerged (U), are Unknown
856           (X), or have had their pairing Broken (B). Any combination of the
857           filter characters (including none) can be used. When *
858           (All-or-none) is added to the combination, all paths are selected
859           if there is any file that matches other criteria in the comparison;
860           if there is no file that matches other criteria, nothing is
861           selected.
862
863           Also, these upper-case letters can be downcased to exclude. E.g.
864           --diff-filter=ad excludes added and deleted paths.
865
866           Note that not all diffs can feature all types. For instance, diffs
867           from the index to the working tree can never have Added entries
868           (because the set of paths included in the diff is limited by what
869           is in the index). Similarly, copied and renamed entries cannot
870           appear if detection for those types is disabled.
871
872       -S<string>
873           Look for differences that change the number of occurrences of the
874           specified string (i.e. addition/deletion) in a file. Intended for
875           the scripter’s use.
876
877           It is useful when you’re looking for an exact block of code (like a
878           struct), and want to know the history of that block since it first
879           came into being: use the feature iteratively to feed the
880           interesting block in the preimage back into -S, and keep going
881           until you get the very first version of the block.
882
883       -G<regex>
884           Look for differences whose patch text contains added/removed lines
885           that match <regex>.
886
887           To illustrate the difference between -S<regex> --pickaxe-regex and
888           -G<regex>, consider a commit with the following diff in the same
889           file:
890
891               +    return !regexec(regexp, two->ptr, 1, &regmatch, 0);
892               ...
893               -    hit = !regexec(regexp, mf2.ptr, 1, &regmatch, 0);
894
895           While git log -G"regexec\(regexp" will show this commit, git log
896           -S"regexec\(regexp" --pickaxe-regex will not (because the number of
897           occurrences of that string did not change).
898
899           See the pickaxe entry in gitdiffcore(7) for more information.
900
901       --find-object=<object-id>
902           Look for differences that change the number of occurrences of the
903           specified object. Similar to -S, just the argument is different in
904           that it doesn’t search for a specific string but for a specific
905           object id.
906
907           The object can be a blob or a submodule commit. It implies the -t
908           option in git-log to also find trees.
909
910       --pickaxe-all
911           When -S or -G finds a change, show all the changes in that
912           changeset, not just the files that contain the change in <string>.
913
914       --pickaxe-regex
915           Treat the <string> given to -S as an extended POSIX regular
916           expression to match.
917
918       -O<orderfile>
919           Control the order in which files appear in the output. This
920           overrides the diff.orderFile configuration variable (see git-
921           config(1)). To cancel diff.orderFile, use -O/dev/null.
922
923           The output order is determined by the order of glob patterns in
924           <orderfile>. All files with pathnames that match the first pattern
925           are output first, all files with pathnames that match the second
926           pattern (but not the first) are output next, and so on. All files
927           with pathnames that do not match any pattern are output last, as if
928           there was an implicit match-all pattern at the end of the file. If
929           multiple pathnames have the same rank (they match the same pattern
930           but no earlier patterns), their output order relative to each other
931           is the normal order.
932
933           <orderfile> is parsed as follows:
934
935           ·   Blank lines are ignored, so they can be used as separators for
936               readability.
937
938           ·   Lines starting with a hash ("#") are ignored, so they can be
939               used for comments. Add a backslash ("\") to the beginning of
940               the pattern if it starts with a hash.
941
942           ·   Each other line contains a single pattern.
943
944           Patterns have the same syntax and semantics as patterns used for
945           fnmatch(3) without the FNM_PATHNAME flag, except a pathname also
946           matches a pattern if removing any number of the final pathname
947           components matches the pattern. For example, the pattern "foo*bar"
948           matches "fooasdfbar" and "foo/bar/baz/asdf" but not "foobarx".
949
950       -R
951           Swap two inputs; that is, show differences from index or on-disk
952           file to tree contents.
953
954       --relative[=<path>]
955           When run from a subdirectory of the project, it can be told to
956           exclude changes outside the directory and show pathnames relative
957           to it with this option. When you are not in a subdirectory (e.g. in
958           a bare repository), you can name which subdirectory to make the
959           output relative to by giving a <path> as an argument.
960
961       -a, --text
962           Treat all files as text.
963
964       --ignore-cr-at-eol
965           Ignore carriage-return at the end of line when doing a comparison.
966
967       --ignore-space-at-eol
968           Ignore changes in whitespace at EOL.
969
970       -b, --ignore-space-change
971           Ignore changes in amount of whitespace. This ignores whitespace at
972           line end, and considers all other sequences of one or more
973           whitespace characters to be equivalent.
974
975       -w, --ignore-all-space
976           Ignore whitespace when comparing lines. This ignores differences
977           even if one line has whitespace where the other line has none.
978
979       --ignore-blank-lines
980           Ignore changes whose lines are all blank.
981
982       --inter-hunk-context=<lines>
983           Show the context between diff hunks, up to the specified number of
984           lines, thereby fusing hunks that are close to each other. Defaults
985           to diff.interHunkContext or 0 if the config option is unset.
986
987       -W, --function-context
988           Show whole surrounding functions of changes.
989
990       --ext-diff
991           Allow an external diff helper to be executed. If you set an
992           external diff driver with gitattributes(5), you need to use this
993           option with git-log(1) and friends.
994
995       --no-ext-diff
996           Disallow external diff drivers.
997
998       --textconv, --no-textconv
999           Allow (or disallow) external text conversion filters to be run when
1000           comparing binary files. See gitattributes(5) for details. Because
1001           textconv filters are typically a one-way conversion, the resulting
1002           diff is suitable for human consumption, but cannot be applied. For
1003           this reason, textconv filters are enabled by default only for git-
1004           diff(1) and git-log(1), but not for git-format-patch(1) or diff
1005           plumbing commands.
1006
1007       --ignore-submodules[=<when>]
1008           Ignore changes to submodules in the diff generation. <when> can be
1009           either "none", "untracked", "dirty" or "all", which is the default.
1010           Using "none" will consider the submodule modified when it either
1011           contains untracked or modified files or its HEAD differs from the
1012           commit recorded in the superproject and can be used to override any
1013           settings of the ignore option in git-config(1) or gitmodules(5).
1014           When "untracked" is used submodules are not considered dirty when
1015           they only contain untracked content (but they are still scanned for
1016           modified content). Using "dirty" ignores all changes to the work
1017           tree of submodules, only changes to the commits stored in the
1018           superproject are shown (this was the behavior until 1.7.0). Using
1019           "all" hides all changes to submodules.
1020
1021       --src-prefix=<prefix>
1022           Show the given source prefix instead of "a/".
1023
1024       --dst-prefix=<prefix>
1025           Show the given destination prefix instead of "b/".
1026
1027       --no-prefix
1028           Do not show any source or destination prefix.
1029
1030       --line-prefix=<prefix>
1031           Prepend an additional prefix to every line of output.
1032
1033       --ita-invisible-in-index
1034           By default entries added by "git add -N" appear as an existing
1035           empty file in "git diff" and a new file in "git diff --cached".
1036           This option makes the entry appear as a new file in "git diff" and
1037           non-existent in "git diff --cached". This option could be reverted
1038           with --ita-visible-in-index. Both options are experimental and
1039           could be removed in future.
1040
1041       For more detailed explanation on these common options, see also
1042       gitdiffcore(7).
1043

GENERATING PATCHES WITH -P

1045       When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
1046       with a -p option, "git diff" without the --raw option, or "git log"
1047       with the "-p" option, they do not produce the output described above;
1048       instead they produce a patch file. You can customize the creation of
1049       such patches via the GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS
1050       environment variables.
1051
1052       What the -p option produces is slightly different from the traditional
1053       diff format:
1054
1055        1. It is preceded with a "git diff" header that looks like this:
1056
1057               diff --git a/file1 b/file2
1058
1059           The a/ and b/ filenames are the same unless rename/copy is
1060           involved. Especially, even for a creation or a deletion, /dev/null
1061           is not used in place of the a/ or b/ filenames.
1062
1063           When rename/copy is involved, file1 and file2 show the name of the
1064           source file of the rename/copy and the name of the file that
1065           rename/copy produces, respectively.
1066
1067        2. It is followed by one or more extended header lines:
1068
1069               old mode <mode>
1070               new mode <mode>
1071               deleted file mode <mode>
1072               new file mode <mode>
1073               copy from <path>
1074               copy to <path>
1075               rename from <path>
1076               rename to <path>
1077               similarity index <number>
1078               dissimilarity index <number>
1079               index <hash>..<hash> <mode>
1080
1081           File modes are printed as 6-digit octal numbers including the file
1082           type and file permission bits.
1083
1084           Path names in extended headers do not include the a/ and b/
1085           prefixes.
1086
1087           The similarity index is the percentage of unchanged lines, and the
1088           dissimilarity index is the percentage of changed lines. It is a
1089           rounded down integer, followed by a percent sign. The similarity
1090           index value of 100% is thus reserved for two equal files, while
1091           100% dissimilarity means that no line from the old file made it
1092           into the new one.
1093
1094           The index line includes the SHA-1 checksum before and after the
1095           change. The <mode> is included if the file mode does not change;
1096           otherwise, separate lines indicate the old and the new mode.
1097
1098        3. Pathnames with "unusual" characters are quoted as explained for the
1099           configuration variable core.quotePath (see git-config(1)).
1100
1101        4. All the file1 files in the output refer to files before the commit,
1102           and all the file2 files refer to files after the commit. It is
1103           incorrect to apply each change to each file sequentially. For
1104           example, this patch will swap a and b:
1105
1106               diff --git a/a b/b
1107               rename from a
1108               rename to b
1109               diff --git a/b b/a
1110               rename from b
1111               rename to a
1112

COMBINED DIFF FORMAT

1114       Any diff-generating command can take the -c or --cc option to produce a
1115       combined diff when showing a merge. This is the default format when
1116       showing merges with git-diff(1) or git-show(1). Note also that you can
1117       give the -m option to any of these commands to force generation of
1118       diffs with individual parents of a merge.
1119
1120       A combined diff format looks like this:
1121
1122           diff --combined describe.c
1123           index fabadb8,cc95eb0..4866510
1124           --- a/describe.c
1125           +++ b/describe.c
1126           @@@ -98,20 -98,12 +98,20 @@@
1127                   return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
1128             }
1129
1130           - static void describe(char *arg)
1131            -static void describe(struct commit *cmit, int last_one)
1132           ++static void describe(char *arg, int last_one)
1133             {
1134            +      unsigned char sha1[20];
1135            +      struct commit *cmit;
1136                   struct commit_list *list;
1137                   static int initialized = 0;
1138                   struct commit_name *n;
1139
1140            +      if (get_sha1(arg, sha1) < 0)
1141            +              usage(describe_usage);
1142            +      cmit = lookup_commit_reference(sha1);
1143            +      if (!cmit)
1144            +              usage(describe_usage);
1145            +
1146                   if (!initialized) {
1147                           initialized = 1;
1148                           for_each_ref(get_name);
1149
1150
1151
1152        1. It is preceded with a "git diff" header, that looks like this (when
1153           -c option is used):
1154
1155               diff --combined file
1156
1157           or like this (when --cc option is used):
1158
1159               diff --cc file
1160
1161        2. It is followed by one or more extended header lines (this example
1162           shows a merge with two parents):
1163
1164               index <hash>,<hash>..<hash>
1165               mode <mode>,<mode>..<mode>
1166               new file mode <mode>
1167               deleted file mode <mode>,<mode>
1168
1169           The mode <mode>,<mode>..<mode> line appears only if at least one of
1170           the <mode> is different from the rest. Extended headers with
1171           information about detected contents movement (renames and copying
1172           detection) are designed to work with diff of two <tree-ish> and are
1173           not used by combined diff format.
1174
1175        3. It is followed by two-line from-file/to-file header
1176
1177               --- a/file
1178               +++ b/file
1179
1180           Similar to two-line header for traditional unified diff format,
1181           /dev/null is used to signal created or deleted files.
1182
1183        4. Chunk header format is modified to prevent people from accidentally
1184           feeding it to patch -p1. Combined diff format was created for
1185           review of merge commit changes, and was not meant for apply. The
1186           change is similar to the change in the extended index header:
1187
1188               @@@ <from-file-range> <from-file-range> <to-file-range> @@@
1189
1190           There are (number of parents + 1) @ characters in the chunk header
1191           for combined diff format.
1192
1193       Unlike the traditional unified diff format, which shows two files A and
1194       B with a single column that has - (minus — appears in A but removed in
1195       B), + (plus — missing in A but added to B), or " " (space — unchanged)
1196       prefix, this format compares two or more files file1, file2,... with
1197       one file X, and shows how X differs from each of fileN. One column for
1198       each of fileN is prepended to the output line to note how X’s line is
1199       different from it.
1200
1201       A - character in the column N means that the line appears in fileN but
1202       it does not appear in the result. A + character in the column N means
1203       that the line appears in the result, and fileN does not have that line
1204       (in other words, the line was added, from the point of view of that
1205       parent).
1206
1207       In the above example output, the function signature was changed from
1208       both files (hence two - removals from both file1 and file2, plus ++ to
1209       mean one line that was added does not appear in either file1 or file2).
1210       Also eight other lines are the same from file1 but do not appear in
1211       file2 (hence prefixed with +).
1212
1213       When shown by git diff-tree -c, it compares the parents of a merge
1214       commit with the merge result (i.e. file1..fileN are the parents). When
1215       shown by git diff-files -c, it compares the two unresolved merge
1216       parents with the working tree file (i.e. file1 is stage 2 aka "our
1217       version", file2 is stage 3 aka "their version").
1218

EXAMPLES

1220       git show v1.0.0
1221           Shows the tag v1.0.0, along with the object the tags points at.
1222
1223       git show v1.0.0^{tree}
1224           Shows the tree pointed to by the tag v1.0.0.
1225
1226       git show -s --format=%s v1.0.0^{commit}
1227           Shows the subject of the commit pointed to by the tag v1.0.0.
1228
1229       git show next~10:Documentation/README
1230           Shows the contents of the file Documentation/README as they were
1231           current in the 10th last commit of the branch next.
1232
1233       git show master:Makefile master:t/Makefile
1234           Concatenates the contents of said Makefiles in the head of the
1235           branch master.
1236

DISCUSSION

1238       Git is to some extent character encoding agnostic.
1239
1240       ·   The contents of the blob objects are uninterpreted sequences of
1241           bytes. There is no encoding translation at the core level.
1242
1243       ·   Path names are encoded in UTF-8 normalization form C. This applies
1244           to tree objects, the index file, ref names, as well as path names
1245           in command line arguments, environment variables and config files
1246           (.git/config (see git-config(1)), gitignore(5), gitattributes(5)
1247           and gitmodules(5)).
1248
1249           Note that Git at the core level treats path names simply as
1250           sequences of non-NUL bytes, there are no path name encoding
1251           conversions (except on Mac and Windows). Therefore, using non-ASCII
1252           path names will mostly work even on platforms and file systems that
1253           use legacy extended ASCII encodings. However, repositories created
1254           on such systems will not work properly on UTF-8-based systems (e.g.
1255           Linux, Mac, Windows) and vice versa. Additionally, many Git-based
1256           tools simply assume path names to be UTF-8 and will fail to display
1257           other encodings correctly.
1258
1259       ·   Commit log messages are typically encoded in UTF-8, but other
1260           extended ASCII encodings are also supported. This includes
1261           ISO-8859-x, CP125x and many others, but not UTF-16/32, EBCDIC and
1262           CJK multi-byte encodings (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).
1263
1264       Although we encourage that the commit log messages are encoded in
1265       UTF-8, both the core and Git Porcelain are designed not to force UTF-8
1266       on projects. If all participants of a particular project find it more
1267       convenient to use legacy encodings, Git does not forbid it. However,
1268       there are a few things to keep in mind.
1269
1270        1. git commit and git commit-tree issues a warning if the commit log
1271           message given to it does not look like a valid UTF-8 string, unless
1272           you explicitly say your project uses a legacy encoding. The way to
1273           say this is to have i18n.commitencoding in .git/config file, like
1274           this:
1275
1276               [i18n]
1277                       commitEncoding = ISO-8859-1
1278
1279           Commit objects created with the above setting record the value of
1280           i18n.commitEncoding in its encoding header. This is to help other
1281           people who look at them later. Lack of this header implies that the
1282           commit log message is encoded in UTF-8.
1283
1284        2. git log, git show, git blame and friends look at the encoding
1285           header of a commit object, and try to re-code the log message into
1286           UTF-8 unless otherwise specified. You can specify the desired
1287           output encoding with i18n.logOutputEncoding in .git/config file,
1288           like this:
1289
1290               [i18n]
1291                       logOutputEncoding = ISO-8859-1
1292
1293           If you do not have this configuration variable, the value of
1294           i18n.commitEncoding is used instead.
1295
1296       Note that we deliberately chose not to re-code the commit log message
1297       when a commit is made to force UTF-8 at the commit object level,
1298       because re-coding to UTF-8 is not necessarily a reversible operation.
1299

GIT

1301       Part of the git(1) suite
1302
1303
1304
1305Git 2.20.1                        12/15/2018                       GIT-SHOW(1)
Impressum