1GIT-SHOW(1) Git Manual GIT-SHOW(1)
2
6 git-show - Show various types of objects
7
9 git show [<options>] [<object>...]
10
13 Shows one or more objects (blobs, trees, tags and commits).
14 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 For tags, it shows the tag message and the referenced objects.
19 For trees, it shows the names (equivalent to git ls-tree with
21 --name-only).
22 For plain blobs, it shows the plain contents.
24 The command takes options applicable to the git diff-tree command to
26 control how the changes the commit introduces are shown.
27 This manual page describes only the most frequently used options.
29
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 --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 See the "PRETTY FORMATS" section for some additional details for
44 each format. When =<format> part is omitted, it defaults to medium.
45 Note: you can specify the default pretty format in the repository
47 configuration (see git-config(1)).
48 --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 This should make "--pretty=oneline" a whole lot more readable for
56 people using 80-column terminals.
57 --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 --oneline
64 This is a shorthand for "--pretty=oneline --abbrev-commit" used
65 together.
66 --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 --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 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 --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 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 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 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 --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 --show-notes[=<treeish>], --[no-]standard-notes
115 These options are deprecated. Use the above --notes/--no-notes
116 options instead.
117 --show-signature
119 Check the validity of a signed commit object by passing the
120 signature to gpg --verify and show the output.
121
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 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 · oneline
137 <sha1> <title line>
139 This is designed to be as compact as possible.
141 · short
143 commit <sha1>
145 Author: <author>
146 <title line>
148 · medium
150 commit <sha1>
152 Author: <author>
153 Date: <author date>
154 <title line>
156 <full commit message>
158 · full
160 commit <sha1>
162 Author: <author>
163 Commit: <committer>
164 <title line>
166 <full commit message>
168 · fuller
170 commit <sha1>
172 Author: <author>
173 AuthorDate: <author date>
174 Commit: <committer>
175 CommitDate: <committer date>
176 <title line>
178 <full commit message>
180 · email
182 From <sha1> <date>
184 From: <author>
185 Date: <author date>
186 Subject: [PATCH] <title line>
187 <full commit message>
189 · raw
191 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 · format:<string>
202 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 E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
208 would show something like this:
209 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 The placeholders are:
214 · %H: commit hash
216 · %h: abbreviated commit hash
218 · %T: tree hash
220 · %t: abbreviated tree hash
222 · %P: parent hashes
224 · %p: abbreviated parent hashes
226 · %an: author name
228 · %aN: author name (respecting .mailmap, see git-shortlog(1) or
230 git-blame(1))
231 · %ae: author email
233 · %aE: author email (respecting .mailmap, see git-shortlog(1) or
235 git-blame(1))
236 · %ad: author date (format respects --date= option)
238 · %aD: author date, RFC2822 style
240 · %ar: author date, relative
242 · %at: author date, UNIX timestamp
244 · %ai: author date, ISO 8601-like format
246 · %aI: author date, strict ISO 8601 format
248 · %cn: committer name
250 · %cN: committer name (respecting .mailmap, see git-shortlog(1)
252 or git-blame(1))
253 · %ce: committer email
255 · %cE: committer email (respecting .mailmap, see git-shortlog(1)
257 or git-blame(1))
258 · %cd: committer date (format respects --date= option)
260 · %cD: committer date, RFC2822 style
262 · %cr: committer date, relative
264 · %ct: committer date, UNIX timestamp
266 · %ci: committer date, ISO 8601-like format
268 · %cI: committer date, strict ISO 8601 format
270 · %d: ref names, like the --decorate option of git-log(1)
272 · %D: ref names without the " (", ")" wrapping.
274 · %e: encoding
276 · %s: subject
278 · %f: sanitized subject line, suitable for a filename
280 · %b: body
282 · %B: raw body (unwrapped subject and body)
284 · %N: commit notes
286 · %GG: raw verification message from GPG for a signed commit
288 · %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 · %GS: show the name of the signer for a signed commit
297 · %GK: show the key used to sign a signed commit
299 · %gD: reflog selector, e.g., refs/stash@{1} or refs/stash@{2
301 minutes ago}; the format follows the rules described for the -g
302 option. The portion before the @ is the refname as given on the
303 command line (so git log -g refs/heads/master would yield
304 refs/heads/master@{0}).
305 · %gd: shortened reflog selector; same as %gD, but the refname
307 portion is shortened for human readability (so
308 refs/heads/master becomes just master).
309 · %gn: reflog identity name
311 · %gN: reflog identity name (respecting .mailmap, see git-
313 shortlog(1) or git-blame(1))
314 · %ge: reflog identity email
316 · %gE: reflog identity email (respecting .mailmap, see git-
318 shortlog(1) or git-blame(1))
319 · %gs: reflog subject
321 · %Cred: switch color to red
323 · %Cgreen: switch color to green
325 · %Cblue: switch color to blue
327 · %Creset: reset color
329 · %C(...): color specification, as described under Values in the
331 "CONFIGURATION FILE" section of git-config(1). By default,
332 colors are shown only when enabled for log output (by
333 color.diff, color.ui, or --color, and respecting the auto
334 settings of the former if we are going to a terminal).
335 %C(auto,...) is accepted as a historical synonym for the
336 default (e.g., %C(auto,red)). Specifying %C(always,...) will
337 show the colors even when color is not otherwise enabled
338 (though consider just using `--color=always to enable color for
339 the whole output, including this format and anything else git
340 might color). auto alone (i.e. %C(auto)) will turn on auto
341 coloring on the next placeholders until the color is switched
342 again.
343 · %m: left (<), right (>) or boundary (-) mark
345 · %n: newline
347 · %%: a raw %
349 · %x00: print a byte from a hex code
351 · %w([<w>[,<i1>[,<i2>]]]): switch line wrapping, like the -w
353 option of git-shortlog(1).
354 · %<(<N>[,trunc|ltrunc|mtrunc]): make the next placeholder take
356 at least N columns, padding spaces on the right if necessary.
357 Optionally truncate at the beginning (ltrunc), the middle
358 (mtrunc) or the end (trunc) if the output is longer than N
359 columns. Note that truncating only works correctly with N >= 2.
360 · %<|(<N>): make the next placeholder take at least until Nth
362 columns, padding spaces on the right if necessary
363 · %>(<N>), %>|(<N>): similar to %<(<N>), %<|(<N>) respectively,
365 but padding spaces on the left
366 · %>>(<N>), %>>|(<N>): similar to %>(<N>), %>|(<N>) respectively,
368 except that if the next placeholder takes more spaces than
369 given and there are spaces on its left, use those spaces
370 · %><(<N>), %><|(<N>): similar to %<(<N>), %<|(<N>) respectively,
372 but padding both sides (i.e. the text is centered)
373 · %(trailers[:options]): display the trailers of the body as
375 interpreted by git-interpret-trailers(1). The trailers string
376 may be followed by a colon and zero or more comma-separated
377 options. If the only option is given, omit non-trailer lines
378 from the trailer block. If the unfold option is given, behave
379 as if interpret-trailer’s --unfold option was given. E.g.,
380 %(trailers:only,unfold) to do both.
381 Note
383 Some placeholders may depend on other options given to the revision
384 traversal engine. For example, the %g* reflog options will insert
385 an empty string unless we are traversing reflog entries (e.g., by
386 git log -g). The %d and %D placeholders will use the "short"
387 decoration format if --decorate was not already provided on the
388 command line.
389 If you add a + (plus sign) after % of a placeholder, a line-feed is
391 inserted immediately before the expansion if and only if the
392 placeholder expands to a non-empty string.
393 If you add a - (minus sign) after % of a placeholder, all consecutive
395 line-feeds immediately preceding the expansion are deleted if and only
396 if the placeholder expands to an empty string.
397 If you add a ` ` (space) after % of a placeholder, a space is inserted
399 immediately before the expansion if and only if the placeholder expands
400 to a non-empty string.
401 · tformat:
403 The tformat: format works exactly like format:, except that it
405 provides "terminator" semantics instead of "separator" semantics.
406 In other words, each commit has the message terminator character
407 (usually a newline) appended, rather than a separator placed
408 between entries. This means that the final entry of a single-line
409 format will be properly terminated with a new line, just as the
410 "oneline" format does. For example:
411 $ git log -2 --pretty=format:%h 4da45bef \
413 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
414 4da45be
415 7134973 -- NO NEWLINE
416 $ git log -2 --pretty=tformat:%h 4da45bef \
418 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
419 4da45be
420 7134973
421 In addition, any unrecognized string that has a % in it is
423 interpreted as if it has tformat: in front of it. For example,
424 these two are equivalent:
425 $ git log -2 --pretty=tformat:%h 4da45bef
427 $ git log -2 --pretty=%h 4da45bef
428
431 -p, -u, --patch
432 Generate patch (see section on generating patches).
433 -s, --no-patch
435 Suppress diff output. Useful for commands like git show that show
436 the patch by default, or to cancel the effect of --patch.
437 -U<n>, --unified=<n>
439 Generate diffs with <n> lines of context instead of the usual
440 three. Implies -p.
441 --raw
443 For each commit, show a summary of changes using the raw diff
444 format. See the "RAW OUTPUT FORMAT" section of git-diff(1). This is
445 different from showing the log itself in raw format, which you can
446 achieve with --format=raw.
447 --patch-with-raw
449 Synonym for -p --raw.
450 --indent-heuristic
452 Enable the heuristic that shifts diff hunk boundaries to make
453 patches easier to read. This is the default.
454 --no-indent-heuristic
456 Disable the indent heuristic.
457 --minimal
459 Spend extra time to make sure the smallest possible diff is
460 produced.
461 --patience
463 Generate a diff using the "patience diff" algorithm.
464 --histogram
466 Generate a diff using the "histogram diff" algorithm.
467 --anchored=<text>
469 Generate a diff using the "anchored diff" algorithm.
470 This option may be specified more than once.
472 If a line exists in both the source and destination, exists only
474 once, and starts with this text, this algorithm attempts to prevent
475 it from appearing as a deletion or addition in the output. It uses
476 the "patience diff" algorithm internally.
477 --diff-algorithm={patience|minimal|histogram|myers}
479 Choose a diff algorithm. The variants are as follows:
480 default, myers
482 The basic greedy diff algorithm. Currently, this is the
483 default.
484 minimal
486 Spend extra time to make sure the smallest possible diff is
487 produced.
488 patience
490 Use "patience diff" algorithm when generating patches.
491 histogram
493 This algorithm extends the patience algorithm to "support
494 low-occurrence common elements".
495 For instance, if you configured the diff.algorithm variable to a
497 non-default value and want to use the default one, then you have to
498 use --diff-algorithm=default option.
499 --stat[=<width>[,<name-width>[,<count>]]]
501 Generate a diffstat. By default, as much space as necessary will be
502 used for the filename part, and the rest for the graph part.
503 Maximum width defaults to terminal width, or 80 columns if not
504 connected to a terminal, and can be overridden by <width>. The
505 width of the filename part can be limited by giving another width
506 <name-width> after a comma. The width of the graph part can be
507 limited by using --stat-graph-width=<width> (affects all commands
508 generating a stat graph) or by setting diff.statGraphWidth=<width>
509 (does not affect git format-patch). By giving a third parameter
510 <count>, you can limit the output to the first <count> lines,
511 followed by ... if there are more.
512 These parameters can also be set individually with
514 --stat-width=<width>, --stat-name-width=<name-width> and
515 --stat-count=<count>.
516 --compact-summary
518 Output a condensed summary of extended header information such as
519 file creations or deletions ("new" or "gone", optionally "+l" if
520 it’s a symlink) and mode changes ("+x" or "-x" for adding or
521 removing executable bit respectively) in diffstat. The information
522 is put between the filename part and the graph part. Implies
523 --stat.
524 --numstat
526 Similar to --stat, but shows number of added and deleted lines in
527 decimal notation and pathname without abbreviation, to make it more
528 machine friendly. For binary files, outputs two - instead of saying
529 0 0.
530 --shortstat
532 Output only the last line of the --stat format containing total
533 number of modified files, as well as number of added and deleted
534 lines.
535 --dirstat[=<param1,param2,...>]
537 Output the distribution of relative amount of changes for each
538 sub-directory. The behavior of --dirstat can be customized by
539 passing it a comma separated list of parameters. The defaults are
540 controlled by the diff.dirstat configuration variable (see git-
541 config(1)). The following parameters are available:
542 changes
544 Compute the dirstat numbers by counting the lines that have
545 been removed from the source, or added to the destination. This
546 ignores the amount of pure code movements within a file. In
547 other words, rearranging lines in a file is not counted as much
548 as other changes. This is the default behavior when no
549 parameter is given.
550 lines
552 Compute the dirstat numbers by doing the regular line-based
553 diff analysis, and summing the removed/added line counts. (For
554 binary files, count 64-byte chunks instead, since binary files
555 have no natural concept of lines). This is a more expensive
556 --dirstat behavior than the changes behavior, but it does count
557 rearranged lines within a file as much as other changes. The
558 resulting output is consistent with what you get from the other
559 --*stat options.
560 files
562 Compute the dirstat numbers by counting the number of files
563 changed. Each changed file counts equally in the dirstat
564 analysis. This is the computationally cheapest --dirstat
565 behavior, since it does not have to look at the file contents
566 at all.
567 cumulative
569 Count changes in a child directory for the parent directory as
570 well. Note that when using cumulative, the sum of the
571 percentages reported may exceed 100%. The default
572 (non-cumulative) behavior can be specified with the
573 noncumulative parameter.
574 <limit>
576 An integer parameter specifies a cut-off percent (3% by
577 default). Directories contributing less than this percentage of
578 the changes are not shown in the output.
579 Example: The following will count changed files, while ignoring
581 directories with less than 10% of the total amount of changed
582 files, and accumulating child directory counts in the parent
583 directories: --dirstat=files,10,cumulative.
584 --summary
586 Output a condensed summary of extended header information such as
587 creations, renames and mode changes.
588 --patch-with-stat
590 Synonym for -p --stat.
591 -z
593 Separate the commits with NULs instead of with new newlines.
594 Also, when --raw or --numstat has been given, do not munge
596 pathnames and use NULs as output field terminators.
597 Without this option, pathnames with "unusual" characters are quoted
599 as explained for the configuration variable core.quotePath (see
600 git-config(1)).
601 --name-only
603 Show only names of changed files.
604 --name-status
606 Show only names and status of changed files. See the description of
607 the --diff-filter option on what the status letters mean.
608 --submodule[=<format>]
610 Specify how differences in submodules are shown. When specifying
611 --submodule=short the short format is used. This format just shows
612 the names of the commits at the beginning and end of the range.
613 When --submodule or --submodule=log is specified, the log format is
614 used. This format lists the commits in the range like git-
615 submodule(1) summary does. When --submodule=diff is specified, the
616 diff format is used. This format shows an inline diff of the
617 changes in the submodule contents between the commit range.
618 Defaults to diff.submodule or the short format if the config option
619 is unset.
620 --color[=<when>]
622 Show colored diff. --color (i.e. without =<when>) is the same as
623 --color=always. <when> can be one of always, never, or auto.
624 --no-color
626 Turn off colored diff. It is the same as --color=never.
627 --color-moved[=<mode>]
629 Moved lines of code are colored differently. The <mode> defaults to
630 no if the option is not given and to zebra if the option with no
631 mode is given. The mode must be one of:
632 no
634 Moved lines are not highlighted.
635 default
637 Is a synonym for zebra. This may change to a more sensible mode
638 in the future.
639 plain
641 Any line that is added in one location and was removed in
642 another location will be colored with color.diff.newMoved.
643 Similarly color.diff.oldMoved will be used for removed lines
644 that are added somewhere else in the diff. This mode picks up
645 any moved line, but it is not very useful in a review to
646 determine if a block of code was moved without permutation.
647 zebra
649 Blocks of moved text of at least 20 alphanumeric characters are
650 detected greedily. The detected blocks are painted using either
651 the color.diff.{old,new}Moved color or
652 color.diff.{old,new}MovedAlternative. The change between the
653 two colors indicates that a new block was detected.
654 dimmed_zebra
656 Similar to zebra, but additional dimming of uninteresting parts
657 of moved code is performed. The bordering lines of two adjacent
658 blocks are considered interesting, the rest is uninteresting.
659 --word-diff[=<mode>]
661 Show a word diff, using the <mode> to delimit changed words. By
662 default, words are delimited by whitespace; see --word-diff-regex
663 below. The <mode> defaults to plain, and must be one of:
664 color
666 Highlight changed words using only colors. Implies --color.
667 plain
669 Show words as [-removed-] and {+added+}. Makes no attempts to
670 escape the delimiters if they appear in the input, so the
671 output may be ambiguous.
672 porcelain
674 Use a special line-based format intended for script
675 consumption. Added/removed/unchanged runs are printed in the
676 usual unified diff format, starting with a +/-/` ` character at
677 the beginning of the line and extending to the end of the line.
678 Newlines in the input are represented by a tilde ~ on a line of
679 its own.
680 none
682 Disable word diff again.
683 Note that despite the name of the first mode, color is used to
685 highlight the changed parts in all modes if enabled.
686 --word-diff-regex=<regex>
688 Use <regex> to decide what a word is, instead of considering runs
689 of non-whitespace to be a word. Also implies --word-diff unless it
690 was already enabled.
691 Every non-overlapping match of the <regex> is considered a word.
693 Anything between these matches is considered whitespace and
694 ignored(!) for the purposes of finding differences. You may want to
695 append |[^[:space:]] to your regular expression to make sure that
696 it matches all non-whitespace characters. A match that contains a
697 newline is silently truncated(!) at the newline.
698 For example, --word-diff-regex=. will treat each character as a
700 word and, correspondingly, show differences character by character.
701 The regex can also be set via a diff driver or configuration
703 option, see gitattributes(5) or git-config(1). Giving it explicitly
704 overrides any diff driver or configuration setting. Diff drivers
705 override configuration settings.
706 --color-words[=<regex>]
708 Equivalent to --word-diff=color plus (if a regex was specified)
709 --word-diff-regex=<regex>.
710 --no-renames
712 Turn off rename detection, even when the configuration file gives
713 the default to do so.
714 --check
716 Warn if changes introduce conflict markers or whitespace errors.
717 What are considered whitespace errors is controlled by
718 core.whitespace configuration. By default, trailing whitespaces
719 (including lines that consist solely of whitespaces) and a space
720 character that is immediately followed by a tab character inside
721 the initial indent of the line are considered whitespace errors.
722 Exits with non-zero status if problems are found. Not compatible
723 with --exit-code.
724 --ws-error-highlight=<kind>
726 Highlight whitespace errors in the context, old or new lines of the
727 diff. Multiple values are separated by comma, none resets previous
728 values, default reset the list to new and all is a shorthand for
729 old,new,context. When this option is not given, and the
730 configuration variable diff.wsErrorHighlight is not set, only
731 whitespace errors in new lines are highlighted. The whitespace
732 errors are colored with color.diff.whitespace.
733 --full-index
735 Instead of the first handful of characters, show the full pre- and
736 post-image blob object names on the "index" line when generating
737 patch format output.
738 --binary
740 In addition to --full-index, output a binary diff that can be
741 applied with git-apply.
742 --abbrev[=<n>]
744 Instead of showing the full 40-byte hexadecimal object name in
745 diff-raw format output and diff-tree header lines, show only a
746 partial prefix. This is independent of the --full-index option
747 above, which controls the diff-patch output format. Non default
748 number of digits can be specified with --abbrev=<n>.
749 -B[<n>][/<m>], --break-rewrites[=[<n>][/<m>]]
751 Break complete rewrite changes into pairs of delete and create.
752 This serves two purposes:
753 It affects the way a change that amounts to a total rewrite of a
755 file not as a series of deletion and insertion mixed together with
756 a very few lines that happen to match textually as the context, but
757 as a single deletion of everything old followed by a single
758 insertion of everything new, and the number m controls this aspect
759 of the -B option (defaults to 60%). -B/70% specifies that less
760 than 30% of the original should remain in the result for Git to
761 consider it a total rewrite (i.e. otherwise the resulting patch
762 will be a series of deletion and insertion mixed together with
763 context lines).
764 When used with -M, a totally-rewritten file is also considered as
766 the source of a rename (usually -M only considers a file that
767 disappeared as the source of a rename), and the number n controls
768 this aspect of the -B option (defaults to 50%). -B20% specifies
769 that a change with addition and deletion compared to 20% or more of
770 the file’s size are eligible for being picked up as a possible
771 source of a rename to another file.
772 -M[<n>], --find-renames[=<n>]
774 If generating diffs, detect and report renames for each commit. For
775 following files across renames while traversing history, see
776 --follow. If n is specified, it is a threshold on the similarity
777 index (i.e. amount of addition/deletions compared to the file’s
778 size). For example, -M90% means Git should consider a delete/add
779 pair to be a rename if more than 90% of the file hasn’t changed.
780 Without a % sign, the number is to be read as a fraction, with a
781 decimal point before it. I.e., -M5 becomes 0.5, and is thus the
782 same as -M50%. Similarly, -M05 is the same as -M5%. To limit
783 detection to exact renames, use -M100%. The default similarity
784 index is 50%.
785 -C[<n>], --find-copies[=<n>]
787 Detect copies as well as renames. See also --find-copies-harder. If
788 n is specified, it has the same meaning as for -M<n>.
789 --find-copies-harder
791 For performance reasons, by default, -C option finds copies only if
792 the original file of the copy was modified in the same changeset.
793 This flag makes the command inspect unmodified files as candidates
794 for the source of copy. This is a very expensive operation for
795 large projects, so use it with caution. Giving more than one -C
796 option has the same effect.
797 -D, --irreversible-delete
799 Omit the preimage for deletes, i.e. print only the header but not
800 the diff between the preimage and /dev/null. The resulting patch is
801 not meant to be applied with patch or git apply; this is solely for
802 people who want to just concentrate on reviewing the text after the
803 change. In addition, the output obviously lacks enough information
804 to apply such a patch in reverse, even manually, hence the name of
805 the option.
806 When used together with -B, omit also the preimage in the deletion
808 part of a delete/create pair.
809 -l<num>
811 The -M and -C options require O(n^2) processing time where n is the
812 number of potential rename/copy targets. This option prevents
813 rename/copy detection from running if the number of rename/copy
814 targets exceeds the specified number.
815 --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
817 Select only files that are Added (A), Copied (C), Deleted (D),
818 Modified (M), Renamed (R), have their type (i.e. regular file,
819 symlink, submodule, ...) changed (T), are Unmerged (U), are Unknown
820 (X), or have had their pairing Broken (B). Any combination of the
821 filter characters (including none) can be used. When *
822 (All-or-none) is added to the combination, all paths are selected
823 if there is any file that matches other criteria in the comparison;
824 if there is no file that matches other criteria, nothing is
825 selected.
826 Also, these upper-case letters can be downcased to exclude. E.g.
828 --diff-filter=ad excludes added and deleted paths.
829 Note that not all diffs can feature all types. For instance, diffs
831 from the index to the working tree can never have Added entries
832 (because the set of paths included in the diff is limited by what
833 is in the index). Similarly, copied and renamed entries cannot
834 appear if detection for those types is disabled.
835 -S<string>
837 Look for differences that change the number of occurrences of the
838 specified string (i.e. addition/deletion) in a file. Intended for
839 the scripter’s use.
840 It is useful when you’re looking for an exact block of code (like a
842 struct), and want to know the history of that block since it first
843 came into being: use the feature iteratively to feed the
844 interesting block in the preimage back into -S, and keep going
845 until you get the very first version of the block.
846 -G<regex>
848 Look for differences whose patch text contains added/removed lines
849 that match <regex>.
850 To illustrate the difference between -S<regex> --pickaxe-regex and
852 -G<regex>, consider a commit with the following diff in the same
853 file:
854 + return !regexec(regexp, two->ptr, 1, ®match, 0);
856 ...
857 - hit = !regexec(regexp, mf2.ptr, 1, ®match, 0);
858 While git log -G"regexec\(regexp" will show this commit, git log
860 -S"regexec\(regexp" --pickaxe-regex will not (because the number of
861 occurrences of that string did not change).
862 See the pickaxe entry in gitdiffcore(7) for more information.
864 --find-object=<object-id>
866 Look for differences that change the number of occurrences of the
867 specified object. Similar to -S, just the argument is different in
868 that it doesn’t search for a specific string but for a specific
869 object id.
870 The object can be a blob or a submodule commit. It implies the -t
872 option in git-log to also find trees.
873 --pickaxe-all
875 When -S or -G finds a change, show all the changes in that
876 changeset, not just the files that contain the change in <string>.
877 --pickaxe-regex
879 Treat the <string> given to -S as an extended POSIX regular
880 expression to match.
881 -O<orderfile>
883 Control the order in which files appear in the output. This
884 overrides the diff.orderFile configuration variable (see git-
885 config(1)). To cancel diff.orderFile, use -O/dev/null.
886 The output order is determined by the order of glob patterns in
888 <orderfile>. All files with pathnames that match the first pattern
889 are output first, all files with pathnames that match the second
890 pattern (but not the first) are output next, and so on. All files
891 with pathnames that do not match any pattern are output last, as if
892 there was an implicit match-all pattern at the end of the file. If
893 multiple pathnames have the same rank (they match the same pattern
894 but no earlier patterns), their output order relative to each other
895 is the normal order.
896 <orderfile> is parsed as follows:
898 · Blank lines are ignored, so they can be used as separators for
900 readability.
901 · Lines starting with a hash ("#") are ignored, so they can be
903 used for comments. Add a backslash ("\") to the beginning of
904 the pattern if it starts with a hash.
905 · Each other line contains a single pattern.
907 Patterns have the same syntax and semantics as patterns used for
909 fnmatch(3) without the FNM_PATHNAME flag, except a pathname also
910 matches a pattern if removing any number of the final pathname
911 components matches the pattern. For example, the pattern "foo*bar"
912 matches "fooasdfbar" and "foo/bar/baz/asdf" but not "foobarx".
913 -R
915 Swap two inputs; that is, show differences from index or on-disk
916 file to tree contents.
917 --relative[=<path>]
919 When run from a subdirectory of the project, it can be told to
920 exclude changes outside the directory and show pathnames relative
921 to it with this option. When you are not in a subdirectory (e.g. in
922 a bare repository), you can name which subdirectory to make the
923 output relative to by giving a <path> as an argument.
924 -a, --text
926 Treat all files as text.
927 --ignore-cr-at-eol
929 Ignore carriage-return at the end of line when doing a comparison.
930 --ignore-space-at-eol
932 Ignore changes in whitespace at EOL.
933 -b, --ignore-space-change
935 Ignore changes in amount of whitespace. This ignores whitespace at
936 line end, and considers all other sequences of one or more
937 whitespace characters to be equivalent.
938 -w, --ignore-all-space
940 Ignore whitespace when comparing lines. This ignores differences
941 even if one line has whitespace where the other line has none.
942 --ignore-blank-lines
944 Ignore changes whose lines are all blank.
945 --inter-hunk-context=<lines>
947 Show the context between diff hunks, up to the specified number of
948 lines, thereby fusing hunks that are close to each other. Defaults
949 to diff.interHunkContext or 0 if the config option is unset.
950 -W, --function-context
952 Show whole surrounding functions of changes.
953 --ext-diff
955 Allow an external diff helper to be executed. If you set an
956 external diff driver with gitattributes(5), you need to use this
957 option with git-log(1) and friends.
958 --no-ext-diff
960 Disallow external diff drivers.
961 --textconv, --no-textconv
963 Allow (or disallow) external text conversion filters to be run when
964 comparing binary files. See gitattributes(5) for details. Because
965 textconv filters are typically a one-way conversion, the resulting
966 diff is suitable for human consumption, but cannot be applied. For
967 this reason, textconv filters are enabled by default only for git-
968 diff(1) and git-log(1), but not for git-format-patch(1) or diff
969 plumbing commands.
970 --ignore-submodules[=<when>]
972 Ignore changes to submodules in the diff generation. <when> can be
973 either "none", "untracked", "dirty" or "all", which is the default.
974 Using "none" will consider the submodule modified when it either
975 contains untracked or modified files or its HEAD differs from the
976 commit recorded in the superproject and can be used to override any
977 settings of the ignore option in git-config(1) or gitmodules(5).
978 When "untracked" is used submodules are not considered dirty when
979 they only contain untracked content (but they are still scanned for
980 modified content). Using "dirty" ignores all changes to the work
981 tree of submodules, only changes to the commits stored in the
982 superproject are shown (this was the behavior until 1.7.0). Using
983 "all" hides all changes to submodules.
984 --src-prefix=<prefix>
986 Show the given source prefix instead of "a/".
987 --dst-prefix=<prefix>
989 Show the given destination prefix instead of "b/".
990 --no-prefix
992 Do not show any source or destination prefix.
993 --line-prefix=<prefix>
995 Prepend an additional prefix to every line of output.
996 --ita-invisible-in-index
998 By default entries added by "git add -N" appear as an existing
999 empty file in "git diff" and a new file in "git diff --cached".
1000 This option makes the entry appear as a new file in "git diff" and
1001 non-existent in "git diff --cached". This option could be reverted
1002 with --ita-visible-in-index. Both options are experimental and
1003 could be removed in future.
1004 For more detailed explanation on these common options, see also
1006 gitdiffcore(7).
1007
1009 When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
1010 with a -p option, "git diff" without the --raw option, or "git log"
1011 with the "-p" option, they do not produce the output described above;
1012 instead they produce a patch file. You can customize the creation of
1013 such patches via the GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS
1014 environment variables.
1015 What the -p option produces is slightly different from the traditional
1017 diff format:
1018 1. It is preceded with a "git diff" header that looks like this:
1020 diff --git a/file1 b/file2
1022 The a/ and b/ filenames are the same unless rename/copy is
1024 involved. Especially, even for a creation or a deletion, /dev/null
1025 is not used in place of the a/ or b/ filenames.
1026 When rename/copy is involved, file1 and file2 show the name of the
1028 source file of the rename/copy and the name of the file that
1029 rename/copy produces, respectively.
1030 2. It is followed by one or more extended header lines:
1032 old mode <mode>
1034 new mode <mode>
1035 deleted file mode <mode>
1036 new file mode <mode>
1037 copy from <path>
1038 copy to <path>
1039 rename from <path>
1040 rename to <path>
1041 similarity index <number>
1042 dissimilarity index <number>
1043 index <hash>..<hash> <mode>
1044 File modes are printed as 6-digit octal numbers including the file
1046 type and file permission bits.
1047 Path names in extended headers do not include the a/ and b/
1049 prefixes.
1050 The similarity index is the percentage of unchanged lines, and the
1052 dissimilarity index is the percentage of changed lines. It is a
1053 rounded down integer, followed by a percent sign. The similarity
1054 index value of 100% is thus reserved for two equal files, while
1055 100% dissimilarity means that no line from the old file made it
1056 into the new one.
1057 The index line includes the SHA-1 checksum before and after the
1059 change. The <mode> is included if the file mode does not change;
1060 otherwise, separate lines indicate the old and the new mode.
1061 3. Pathnames with "unusual" characters are quoted as explained for the
1063 configuration variable core.quotePath (see git-config(1)).
1064 4. All the file1 files in the output refer to files before the commit,
1066 and all the file2 files refer to files after the commit. It is
1067 incorrect to apply each change to each file sequentially. For
1068 example, this patch will swap a and b:
1069 diff --git a/a b/b
1071 rename from a
1072 rename to b
1073 diff --git a/b b/a
1074 rename from b
1075 rename to a
1076
1078 Any diff-generating command can take the -c or --cc option to produce a
1079 combined diff when showing a merge. This is the default format when
1080 showing merges with git-diff(1) or git-show(1). Note also that you can
1081 give the -m option to any of these commands to force generation of
1082 diffs with individual parents of a merge.
1083 A combined diff format looks like this:
1085 diff --combined describe.c
1087 index fabadb8,cc95eb0..4866510
1088 --- a/describe.c
1089 +++ b/describe.c
1090 @@@ -98,20 -98,12 +98,20 @@@
1091 return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
1092 }
1093 - static void describe(char *arg)
1095 -static void describe(struct commit *cmit, int last_one)
1096 ++static void describe(char *arg, int last_one)
1097 {
1098 + unsigned char sha1[20];
1099 + struct commit *cmit;
1100 struct commit_list *list;
1101 static int initialized = 0;
1102 struct commit_name *n;
1103 + if (get_sha1(arg, sha1) < 0)
1105 + usage(describe_usage);
1106 + cmit = lookup_commit_reference(sha1);
1107 + if (!cmit)
1108 + usage(describe_usage);
1109 +
1110 if (!initialized) {
1111 initialized = 1;
1112 for_each_ref(get_name);
1113 1. It is preceded with a "git diff" header, that looks like this (when
1117 -c option is used):
1118 diff --combined file
1120 or like this (when --cc option is used):
1122 diff --cc file
1124 2. It is followed by one or more extended header lines (this example
1126 shows a merge with two parents):
1127 index <hash>,<hash>..<hash>
1129 mode <mode>,<mode>..<mode>
1130 new file mode <mode>
1131 deleted file mode <mode>,<mode>
1132 The mode <mode>,<mode>..<mode> line appears only if at least one of
1134 the <mode> is different from the rest. Extended headers with
1135 information about detected contents movement (renames and copying
1136 detection) are designed to work with diff of two <tree-ish> and are
1137 not used by combined diff format.
1138 3. It is followed by two-line from-file/to-file header
1140 --- a/file
1142 +++ b/file
1143 Similar to two-line header for traditional unified diff format,
1145 /dev/null is used to signal created or deleted files.
1146 4. Chunk header format is modified to prevent people from accidentally
1148 feeding it to patch -p1. Combined diff format was created for
1149 review of merge commit changes, and was not meant for apply. The
1150 change is similar to the change in the extended index header:
1151 @@@ <from-file-range> <from-file-range> <to-file-range> @@@
1153 There are (number of parents + 1) @ characters in the chunk header
1155 for combined diff format.
1156 Unlike the traditional unified diff format, which shows two files A and
1158 B with a single column that has - (minus — appears in A but removed in
1159 B), + (plus — missing in A but added to B), or " " (space — unchanged)
1160 prefix, this format compares two or more files file1, file2,... with
1161 one file X, and shows how X differs from each of fileN. One column for
1162 each of fileN is prepended to the output line to note how X’s line is
1163 different from it.
1164 A - character in the column N means that the line appears in fileN but
1166 it does not appear in the result. A + character in the column N means
1167 that the line appears in the result, and fileN does not have that line
1168 (in other words, the line was added, from the point of view of that
1169 parent).
1170 In the above example output, the function signature was changed from
1172 both files (hence two - removals from both file1 and file2, plus ++ to
1173 mean one line that was added does not appear in either file1 or file2).
1174 Also eight other lines are the same from file1 but do not appear in
1175 file2 (hence prefixed with +).
1176 When shown by git diff-tree -c, it compares the parents of a merge
1178 commit with the merge result (i.e. file1..fileN are the parents). When
1179 shown by git diff-files -c, it compares the two unresolved merge
1180 parents with the working tree file (i.e. file1 is stage 2 aka "our
1181 version", file2 is stage 3 aka "their version").
1182
1184 git show v1.0.0
1185 Shows the tag v1.0.0, along with the object the tags points at.
1186 git show v1.0.0^{tree}
1188 Shows the tree pointed to by the tag v1.0.0.
1189 git show -s --format=%s v1.0.0^{commit}
1191 Shows the subject of the commit pointed to by the tag v1.0.0.
1192 git show next~10:Documentation/README
1194 Shows the contents of the file Documentation/README as they were
1195 current in the 10th last commit of the branch next.
1196 git show master:Makefile master:t/Makefile
1198 Concatenates the contents of said Makefiles in the head of the
1199 branch master.
1200
1202 Git is to some extent character encoding agnostic.
1203 · The contents of the blob objects are uninterpreted sequences of
1205 bytes. There is no encoding translation at the core level.
1206 · Path names are encoded in UTF-8 normalization form C. This applies
1208 to tree objects, the index file, ref names, as well as path names
1209 in command line arguments, environment variables and config files
1210 (.git/config (see git-config(1)), gitignore(5), gitattributes(5)
1211 and gitmodules(5)).
1212 Note that Git at the core level treats path names simply as
1214 sequences of non-NUL bytes, there are no path name encoding
1215 conversions (except on Mac and Windows). Therefore, using non-ASCII
1216 path names will mostly work even on platforms and file systems that
1217 use legacy extended ASCII encodings. However, repositories created
1218 on such systems will not work properly on UTF-8-based systems (e.g.
1219 Linux, Mac, Windows) and vice versa. Additionally, many Git-based
1220 tools simply assume path names to be UTF-8 and will fail to display
1221 other encodings correctly.
1222 · Commit log messages are typically encoded in UTF-8, but other
1224 extended ASCII encodings are also supported. This includes
1225 ISO-8859-x, CP125x and many others, but not UTF-16/32, EBCDIC and
1226 CJK multi-byte encodings (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).
1227 Although we encourage that the commit log messages are encoded in
1229 UTF-8, both the core and Git Porcelain are designed not to force UTF-8
1230 on projects. If all participants of a particular project find it more
1231 convenient to use legacy encodings, Git does not forbid it. However,
1232 there are a few things to keep in mind.
1233 1. git commit and git commit-tree issues a warning if the commit log
1235 message given to it does not look like a valid UTF-8 string, unless
1236 you explicitly say your project uses a legacy encoding. The way to
1237 say this is to have i18n.commitencoding in .git/config file, like
1238 this:
1239 [i18n]
1241 commitEncoding = ISO-8859-1
1242 Commit objects created with the above setting record the value of
1244 i18n.commitEncoding in its encoding header. This is to help other
1245 people who look at them later. Lack of this header implies that the
1246 commit log message is encoded in UTF-8.
1247 2. git log, git show, git blame and friends look at the encoding
1249 header of a commit object, and try to re-code the log message into
1250 UTF-8 unless otherwise specified. You can specify the desired
1251 output encoding with i18n.logOutputEncoding in .git/config file,
1252 like this:
1253 [i18n]
1255 logOutputEncoding = ISO-8859-1
1256 If you do not have this configuration variable, the value of
1258 i18n.commitEncoding is used instead.
1259 Note that we deliberately chose not to re-code the commit log message
1261 when a commit is made to force UTF-8 at the commit object level,
1262 because re-coding to UTF-8 is not necessarily a reversible operation.
1263
1265 Part of the git(1) suite
1266Git 2.18.1 05/14/2019 GIT-SHOW(1)