1GIT-LOG(1) Git Manual GIT-LOG(1)
2
6 git-log - Show commit logs
7
9 git log [<options>] [<revision-range>] [[--] <path>...]
10
12 Shows the commit logs.
13 List commits that are reachable by following the parent links from the
15 given commit(s), but exclude commits that are reachable from the one(s)
16 given with a ^ in front of them. The output is given in reverse
17 chronological order by default.
18 You can think of this as a set operation. Commits reachable from any of
20 the commits given on the command line form a set, and then commits
21 reachable from any of the ones given with ^ in front are subtracted
22 from that set. The remaining commits are what comes out in the
23 command’s output. Various other options and paths parameters can be
24 used to further limit the result.
25 Thus, the following command:
27 $ git log foo bar ^baz
29 means "list all the commits which are reachable from foo or bar, but
31 not from baz".
32 A special notation "<commit1>..<commit2>" can be used as a short-hand
34 for "^<commit1> <commit2>". For example, either of the following may be
35 used interchangeably:
36 $ git log origin..HEAD
38 $ git log HEAD ^origin
39 Another special notation is "<commit1>...<commit2>" which is useful for
41 merges. The resulting set of commits is the symmetric difference
42 between the two operands. The following two commands are equivalent:
43 $ git log A B --not $(git merge-base --all A B)
45 $ git log A...B
46 The command takes options applicable to the git-rev-list(1) command to
48 control what is shown and how, and options applicable to the git-
49 diff(1) command to control how the changes each commit introduces are
50 shown.
51
53 --follow
54 Continue listing the history of a file beyond renames (works only
55 for a single file).
56 --no-decorate, --decorate[=short|full|auto|no]
58 Print out the ref names of any commits that are shown. If short is
59 specified, the ref name prefixes refs/heads/, refs/tags/ and
60 refs/remotes/ will not be printed. If full is specified, the full
61 ref name (including prefix) will be printed. If auto is specified,
62 then if the output is going to a terminal, the ref names are shown
63 as if short were given, otherwise no ref names are shown. The
64 option --decorate is short-hand for --decorate=short. Default to
65 configuration value of log.decorate if configured, otherwise, auto.
66 --decorate-refs=<pattern>, --decorate-refs-exclude=<pattern>
68 For each candidate reference, do not use it for decoration if it
69 matches any patterns given to --decorate-refs-exclude or if it
70 doesn’t match any of the patterns given to --decorate-refs. The
71 log.excludeDecoration config option allows excluding refs from the
72 decorations, but an explicit --decorate-refs pattern will override
73 a match in log.excludeDecoration.
74 If none of these options or config settings are given, then
76 references are used as decoration if they match HEAD, refs/heads/,
77 refs/remotes/, refs/stash/, or refs/tags/.
78 --clear-decorations
80 When specified, this option clears all previous --decorate-refs or
81 --decorate-refs-exclude options and relaxes the default decoration
82 filter to include all references. This option is assumed if the
83 config value log.initialDecorationSet is set to all.
84 --source
86 Print out the ref name given on the command line by which each
87 commit was reached.
88 --[no-]mailmap, --[no-]use-mailmap
90 Use mailmap file to map author and committer names and email
91 addresses to canonical real names and email addresses. See git-
92 shortlog(1).
93 --full-diff
95 Without this flag, git log -p <path>... shows commits that touch
96 the specified paths, and diffs about the same specified paths. With
97 this, the full diff is shown for commits that touch the specified
98 paths; this means that "<path>..." limits only commits, and doesn’t
99 limit diff for those commits.
100 Note that this affects all diff-based output types, e.g. those
102 produced by --stat, etc.
103 --log-size
105 Include a line “log size <number>” in the output for each commit,
106 where <number> is the length of that commit’s message in bytes.
107 Intended to speed up tools that read log messages from git log
108 output by allowing them to allocate space in advance.
109 -L<start>,<end>:<file>, -L:<funcname>:<file>
111 Trace the evolution of the line range given by <start>,<end>, or by
112 the function name regex <funcname>, within the <file>. You may not
113 give any pathspec limiters. This is currently limited to a walk
114 starting from a single revision, i.e., you may only give zero or
115 one positive revision arguments, and <start> and <end> (or
116 <funcname>) must exist in the starting revision. You can specify
117 this option more than once. Implies --patch. Patch output can be
118 suppressed using --no-patch, but other diff formats (namely --raw,
119 --numstat, --shortstat, --dirstat, --summary, --name-only,
120 --name-status, --check) are not currently implemented.
121 <start> and <end> can take one of these forms:
123 • number
125 If <start> or <end> is a number, it specifies an absolute line
127 number (lines count from 1).
128 • /regex/
130 This form will use the first line matching the given POSIX
132 regex. If <start> is a regex, it will search from the end of
133 the previous -L range, if any, otherwise from the start of
134 file. If <start> is ^/regex/, it will search from the start of
135 file. If <end> is a regex, it will search starting at the line
136 given by <start>.
137 • +offset or -offset
139 This is only valid for <end> and will specify a number of lines
141 before or after the line given by <start>.
142 If :<funcname> is given in place of <start> and <end>, it is a
144 regular expression that denotes the range from the first funcname
145 line that matches <funcname>, up to the next funcname line.
146 :<funcname> searches from the end of the previous -L range, if any,
147 otherwise from the start of file. ^:<funcname> searches from the
148 start of file. The function names are determined in the same way as
149 git diff works out patch hunk headers (see Defining a custom
150 hunk-header in gitattributes(5)).
151 <revision-range>
153 Show only commits in the specified revision range. When no
154 <revision-range> is specified, it defaults to HEAD (i.e. the whole
155 history leading to the current commit). origin..HEAD specifies all
156 the commits reachable from the current commit (i.e. HEAD), but not
157 from origin. For a complete list of ways to spell <revision-range>,
158 see the Specifying Ranges section of gitrevisions(7).
159 [--] <path>...
161 Show only commits that are enough to explain how the files that
162 match the specified paths came to be. See History Simplification
163 below for details and other simplification modes.
164 Paths may need to be prefixed with -- to separate them from options
166 or the revision range, when confusion arises.
167 Commit Limiting
169 Besides specifying a range of commits that should be listed using the
170 special notations explained in the description, additional commit
171 limiting may be applied.
172 Using more options generally further limits the output (e.g.
174 --since=<date1> limits to commits newer than <date1>, and using it with
175 --grep=<pattern> further limits to commits whose log message has a line
176 that matches <pattern>), unless otherwise noted.
177 Note that these are applied before commit ordering and formatting
179 options, such as --reverse.
180 -<number>, -n <number>, --max-count=<number>
182 Limit the number of commits to output.
183 --skip=<number>
185 Skip number commits before starting to show the commit output.
186 --since=<date>, --after=<date>
188 Show commits more recent than a specific date.
189 --since-as-filter=<date>
191 Show all commits more recent than a specific date. This visits all
192 commits in the range, rather than stopping at the first commit
193 which is older than a specific date.
194 --until=<date>, --before=<date>
196 Show commits older than a specific date.
197 --author=<pattern>, --committer=<pattern>
199 Limit the commits output to ones with author/committer header lines
200 that match the specified pattern (regular expression). With more
201 than one --author=<pattern>, commits whose author matches any of
202 the given patterns are chosen (similarly for multiple
203 --committer=<pattern>).
204 --grep-reflog=<pattern>
206 Limit the commits output to ones with reflog entries that match the
207 specified pattern (regular expression). With more than one
208 --grep-reflog, commits whose reflog message matches any of the
209 given patterns are chosen. It is an error to use this option unless
210 --walk-reflogs is in use.
211 --grep=<pattern>
213 Limit the commits output to ones with a log message that matches
214 the specified pattern (regular expression). With more than one
215 --grep=<pattern>, commits whose message matches any of the given
216 patterns are chosen (but see --all-match).
217 When --notes is in effect, the message from the notes is matched as
219 if it were part of the log message.
220 --all-match
222 Limit the commits output to ones that match all given --grep,
223 instead of ones that match at least one.
224 --invert-grep
226 Limit the commits output to ones with a log message that do not
227 match the pattern specified with --grep=<pattern>.
228 -i, --regexp-ignore-case
230 Match the regular expression limiting patterns without regard to
231 letter case.
232 --basic-regexp
234 Consider the limiting patterns to be basic regular expressions;
235 this is the default.
236 -E, --extended-regexp
238 Consider the limiting patterns to be extended regular expressions
239 instead of the default basic regular expressions.
240 -F, --fixed-strings
242 Consider the limiting patterns to be fixed strings (don’t interpret
243 pattern as a regular expression).
244 -P, --perl-regexp
246 Consider the limiting patterns to be Perl-compatible regular
247 expressions.
248 Support for these types of regular expressions is an optional
250 compile-time dependency. If Git wasn’t compiled with support for
251 them providing this option will cause it to die.
252 --remove-empty
254 Stop when a given path disappears from the tree.
255 --merges
257 Print only merge commits. This is exactly the same as
258 --min-parents=2.
259 --no-merges
261 Do not print commits with more than one parent. This is exactly the
262 same as --max-parents=1.
263 --min-parents=<number>, --max-parents=<number>, --no-min-parents,
265 --no-max-parents
266 Show only commits which have at least (or at most) that many parent
267 commits. In particular, --max-parents=1 is the same as --no-merges,
268 --min-parents=2 is the same as --merges. --max-parents=0 gives all
269 root commits and --min-parents=3 all octopus merges.
270 --no-min-parents and --no-max-parents reset these limits (to no
272 limit) again. Equivalent forms are --min-parents=0 (any commit has
273 0 or more parents) and --max-parents=-1 (negative numbers denote no
274 upper limit).
275 --first-parent
277 When finding commits to include, follow only the first parent
278 commit upon seeing a merge commit. This option can give a better
279 overview when viewing the evolution of a particular topic branch,
280 because merges into a topic branch tend to be only about adjusting
281 to updated upstream from time to time, and this option allows you
282 to ignore the individual commits brought in to your history by such
283 a merge.
284 This option also changes default diff format for merge commits to
286 first-parent, see --diff-merges=first-parent for details.
287 --exclude-first-parent-only
289 When finding commits to exclude (with a ^), follow only the first
290 parent commit upon seeing a merge commit. This can be used to find
291 the set of changes in a topic branch from the point where it
292 diverged from the remote branch, given that arbitrary merges can be
293 valid topic branch changes.
294 --not
296 Reverses the meaning of the ^ prefix (or lack thereof) for all
297 following revision specifiers, up to the next --not. When used on
298 the command line before --stdin, the revisions passed through stdin
299 will not be affected by it. Conversely, when passed via standard
300 input, the revisions passed on the command line will not be
301 affected by it.
302 --all
304 Pretend as if all the refs in refs/, along with HEAD, are listed on
305 the command line as <commit>.
306 --branches[=<pattern>]
308 Pretend as if all the refs in refs/heads are listed on the command
309 line as <commit>. If <pattern> is given, limit branches to ones
310 matching given shell glob. If pattern lacks ?, *, or [, /* at the
311 end is implied.
312 --tags[=<pattern>]
314 Pretend as if all the refs in refs/tags are listed on the command
315 line as <commit>. If <pattern> is given, limit tags to ones
316 matching given shell glob. If pattern lacks ?, *, or [, /* at the
317 end is implied.
318 --remotes[=<pattern>]
320 Pretend as if all the refs in refs/remotes are listed on the
321 command line as <commit>. If <pattern> is given, limit
322 remote-tracking branches to ones matching given shell glob. If
323 pattern lacks ?, *, or [, /* at the end is implied.
324 --glob=<glob-pattern>
326 Pretend as if all the refs matching shell glob <glob-pattern> are
327 listed on the command line as <commit>. Leading refs/, is
328 automatically prepended if missing. If pattern lacks ?, *, or [, /*
329 at the end is implied.
330 --exclude=<glob-pattern>
332 Do not include refs matching <glob-pattern> that the next --all,
333 --branches, --tags, --remotes, or --glob would otherwise consider.
334 Repetitions of this option accumulate exclusion patterns up to the
335 next --all, --branches, --tags, --remotes, or --glob option (other
336 options or arguments do not clear accumulated patterns).
337 The patterns given should not begin with refs/heads, refs/tags, or
339 refs/remotes when applied to --branches, --tags, or --remotes,
340 respectively, and they must begin with refs/ when applied to --glob
341 or --all. If a trailing /* is intended, it must be given
342 explicitly.
343 --exclude-hidden=[fetch|receive|uploadpack]
345 Do not include refs that would be hidden by git-fetch,
346 git-receive-pack or git-upload-pack by consulting the appropriate
347 fetch.hideRefs, receive.hideRefs or uploadpack.hideRefs
348 configuration along with transfer.hideRefs (see git-config(1)).
349 This option affects the next pseudo-ref option --all or --glob and
350 is cleared after processing them.
351 --reflog
353 Pretend as if all objects mentioned by reflogs are listed on the
354 command line as <commit>.
355 --alternate-refs
357 Pretend as if all objects mentioned as ref tips of alternate
358 repositories were listed on the command line. An alternate
359 repository is any repository whose object directory is specified in
360 objects/info/alternates. The set of included objects may be
361 modified by core.alternateRefsCommand, etc. See git-config(1).
362 --single-worktree
364 By default, all working trees will be examined by the following
365 options when there are more than one (see git-worktree(1)): --all,
366 --reflog and --indexed-objects. This option forces them to examine
367 the current working tree only.
368 --ignore-missing
370 Upon seeing an invalid object name in the input, pretend as if the
371 bad input was not given.
372 --bisect
374 Pretend as if the bad bisection ref refs/bisect/bad was listed and
375 as if it was followed by --not and the good bisection refs
376 refs/bisect/good-* on the command line.
377 --stdin
379 In addition to getting arguments from the command line, read them
380 from standard input as well. This accepts commits and
381 pseudo-options like --all and --glob=. When a -- separator is seen,
382 the following input is treated as paths and used to limit the
383 result. Flags like --not which are read via standard input are only
384 respected for arguments passed in the same way and will not
385 influence any subsequent command line arguments.
386 --cherry-mark
388 Like --cherry-pick (see below) but mark equivalent commits with =
389 rather than omitting them, and inequivalent ones with +.
390 --cherry-pick
392 Omit any commit that introduces the same change as another commit
393 on the “other side” when the set of commits are limited with
394 symmetric difference.
395 For example, if you have two branches, A and B, a usual way to list
397 all commits on only one side of them is with --left-right (see the
398 example below in the description of the --left-right option).
399 However, it shows the commits that were cherry-picked from the
400 other branch (for example, “3rd on b” may be cherry-picked from
401 branch A). With this option, such pairs of commits are excluded
402 from the output.
403 --left-only, --right-only
405 List only commits on the respective side of a symmetric difference,
406 i.e. only those which would be marked < resp. > by --left-right.
407 For example, --cherry-pick --right-only A...B omits those commits
409 from B which are in A or are patch-equivalent to a commit in A. In
410 other words, this lists the + commits from git cherry A B. More
411 precisely, --cherry-pick --right-only --no-merges gives the exact
412 list.
413 --cherry
415 A synonym for --right-only --cherry-mark --no-merges; useful to
416 limit the output to the commits on our side and mark those that
417 have been applied to the other side of a forked history with git
418 log --cherry upstream...mybranch, similar to git cherry upstream
419 mybranch.
420 -g, --walk-reflogs
422 Instead of walking the commit ancestry chain, walk reflog entries
423 from the most recent one to older ones. When this option is used
424 you cannot specify commits to exclude (that is, ^commit,
425 commit1..commit2, and commit1...commit2 notations cannot be used).
426 With --pretty format other than oneline and reference (for obvious
428 reasons), this causes the output to have two extra lines of
429 information taken from the reflog. The reflog designator in the
430 output may be shown as ref@{Nth} (where Nth is the
431 reverse-chronological index in the reflog) or as ref@{timestamp}
432 (with the timestamp for that entry), depending on a few rules:
433 1. If the starting point is specified as ref@{Nth}, show the index
435 format.
436 2. If the starting point was specified as ref@{now}, show the
438 timestamp format.
439 3. If neither was used, but --date was given on the command line,
441 show the timestamp in the format requested by --date.
442 4. Otherwise, show the index format.
444 Under --pretty=oneline, the commit message is prefixed with this
446 information on the same line. This option cannot be combined with
447 --reverse. See also git-reflog(1).
448 Under --pretty=reference, this information will not be shown at
450 all.
451 --merge
453 After a failed merge, show refs that touch files having a conflict
454 and don’t exist on all heads to merge.
455 --boundary
457 Output excluded boundary commits. Boundary commits are prefixed
458 with -.
459 History Simplification
461 Sometimes you are only interested in parts of the history, for example
462 the commits modifying a particular <path>. But there are two parts of
463 History Simplification, one part is selecting the commits and the other
464 is how to do it, as there are various strategies to simplify the
465 history.
466 The following options select the commits to be shown:
468 <paths>
470 Commits modifying the given <paths> are selected.
471 --simplify-by-decoration
473 Commits that are referred by some branch or tag are selected.
474 Note that extra commits can be shown to give a meaningful history.
476 The following options affect the way the simplification is performed:
478 Default mode
480 Simplifies the history to the simplest history explaining the final
481 state of the tree. Simplest because it prunes some side branches if
482 the end result is the same (i.e. merging branches with the same
483 content)
484 --show-pulls
486 Include all commits from the default mode, but also any merge
487 commits that are not TREESAME to the first parent but are TREESAME
488 to a later parent. This mode is helpful for showing the merge
489 commits that "first introduced" a change to a branch.
490 --full-history
492 Same as the default mode, but does not prune some history.
493 --dense
495 Only the selected commits are shown, plus some to have a meaningful
496 history.
497 --sparse
499 All commits in the simplified history are shown.
500 --simplify-merges
502 Additional option to --full-history to remove some needless merges
503 from the resulting history, as there are no selected commits
504 contributing to this merge.
505 --ancestry-path[=<commit>]
507 When given a range of commits to display (e.g. commit1..commit2 or
508 commit2 ^commit1), only display commits in that range that are
509 ancestors of <commit>, descendants of <commit>, or <commit> itself.
510 If no commit is specified, use commit1 (the excluded part of the
511 range) as <commit>. Can be passed multiple times; if so, a commit
512 is included if it is any of the commits given or if it is an
513 ancestor or descendant of one of them.
514 A more detailed explanation follows.
516 Suppose you specified foo as the <paths>. We shall call commits that
518 modify foo !TREESAME, and the rest TREESAME. (In a diff filtered for
519 foo, they look different and equal, respectively.)
520 In the following, we will always refer to the same example history to
522 illustrate the differences between simplification settings. We assume
523 that you are filtering for a file foo in this commit graph:
524 .-A---M---N---O---P---Q
526 / / / / / /
527 I B C D E Y
528 \ / / / / /
529 `-------------' X
530 The horizontal line of history A---Q is taken to be the first parent of
532 each merge. The commits are:
533 • I is the initial commit, in which foo exists with contents “asdf”,
535 and a file quux exists with contents “quux”. Initial commits are
536 compared to an empty tree, so I is !TREESAME.
537 • In A, foo contains just “foo”.
539 • B contains the same change as A. Its merge M is trivial and hence
541 TREESAME to all parents.
542 • C does not change foo, but its merge N changes it to “foobar”, so
544 it is not TREESAME to any parent.
545 • D sets foo to “baz”. Its merge O combines the strings from N and D
547 to “foobarbaz”; i.e., it is not TREESAME to any parent.
548 • E changes quux to “xyzzy”, and its merge P combines the strings to
550 “quux xyzzy”. P is TREESAME to O, but not to E.
551 • X is an independent root commit that added a new file side, and Y
553 modified it. Y is TREESAME to X. Its merge Q added side to P, and
554 Q is TREESAME to P, but not to Y.
555 rev-list walks backwards through history, including or excluding
557 commits based on whether --full-history and/or parent rewriting (via
558 --parents or --children) are used. The following settings are
559 available.
560 Default mode
562 Commits are included if they are not TREESAME to any parent (though
563 this can be changed, see --sparse below). If the commit was a
564 merge, and it was TREESAME to one parent, follow only that parent.
565 (Even if there are several TREESAME parents, follow only one of
566 them.) Otherwise, follow all parents.
567 This results in:
569 .-A---N---O
571 / / /
572 I---------D
573 Note how the rule to only follow the TREESAME parent, if one is
575 available, removed B from consideration entirely. C was considered
576 via N, but is TREESAME. Root commits are compared to an empty tree,
577 so I is !TREESAME.
578 Parent/child relations are only visible with --parents, but that
580 does not affect the commits selected in default mode, so we have
581 shown the parent lines.
582 --full-history without parent rewriting
584 This mode differs from the default in one point: always follow all
585 parents of a merge, even if it is TREESAME to one of them. Even if
586 more than one side of the merge has commits that are included, this
587 does not imply that the merge itself is! In the example, we get
588 I A B N D O P Q
590 M was excluded because it is TREESAME to both parents. E, C and B
592 were all walked, but only B was !TREESAME, so the others do not
593 appear.
594 Note that without parent rewriting, it is not really possible to
596 talk about the parent/child relationships between the commits, so
597 we show them disconnected.
598 --full-history with parent rewriting
600 Ordinary commits are only included if they are !TREESAME (though
601 this can be changed, see --sparse below).
602 Merges are always included. However, their parent list is
604 rewritten: Along each parent, prune away commits that are not
605 included themselves. This results in
606 .-A---M---N---O---P---Q
608 / / / / /
609 I B / D /
610 \ / / / /
611 `-------------'
612 Compare to --full-history without rewriting above. Note that E was
614 pruned away because it is TREESAME, but the parent list of P was
615 rewritten to contain E's parent I. The same happened for C and N,
616 and X, Y and Q.
617 In addition to the above settings, you can change whether TREESAME
619 affects inclusion:
620 --dense
622 Commits that are walked are included if they are not TREESAME to
623 any parent.
624 --sparse
626 All commits that are walked are included.
627 Note that without --full-history, this still simplifies merges: if
629 one of the parents is TREESAME, we follow only that one, so the
630 other sides of the merge are never walked.
631 --simplify-merges
633 First, build a history graph in the same way that --full-history
634 with parent rewriting does (see above).
635 Then simplify each commit C to its replacement C' in the final
637 history according to the following rules:
638 • Set C' to C.
640 • Replace each parent P of C' with its simplification P'. In the
642 process, drop parents that are ancestors of other parents or
643 that are root commits TREESAME to an empty tree, and remove
644 duplicates, but take care to never drop all parents that we are
645 TREESAME to.
646 • If after this parent rewriting, C' is a root or merge commit
648 (has zero or >1 parents), a boundary commit, or !TREESAME, it
649 remains. Otherwise, it is replaced with its only parent.
650 The effect of this is best shown by way of comparing to
652 --full-history with parent rewriting. The example turns into:
653 .-A---M---N---O
655 / / /
656 I B D
657 \ / /
658 `---------'
659 Note the major differences in N, P, and Q over --full-history:
661 • N's parent list had I removed, because it is an ancestor of the
663 other parent M. Still, N remained because it is !TREESAME.
664 • P's parent list similarly had I removed. P was then removed
666 completely, because it had one parent and is TREESAME.
667 • Q's parent list had Y simplified to X. X was then removed,
669 because it was a TREESAME root. Q was then removed completely,
670 because it had one parent and is TREESAME.
671 There is another simplification mode available:
673 --ancestry-path[=<commit>]
675 Limit the displayed commits to those which are an ancestor of
676 <commit>, or which are a descendant of <commit>, or are <commit>
677 itself.
678 As an example use case, consider the following commit history:
680 D---E-------F
682 / \ \
683 B---C---G---H---I---J
684 / \
685 A-------K---------------L--M
686 A regular D..M computes the set of commits that are ancestors of M,
688 but excludes the ones that are ancestors of D. This is useful to
689 see what happened to the history leading to M since D, in the sense
690 that “what does M have that did not exist in D”. The result in this
691 example would be all the commits, except A and B (and D itself, of
692 course).
693 When we want to find out what commits in M are contaminated with
695 the bug introduced by D and need fixing, however, we might want to
696 view only the subset of D..M that are actually descendants of D,
697 i.e. excluding C and K. This is exactly what the --ancestry-path
698 option does. Applied to the D..M range, it results in:
699 E-------F
701 \ \
702 G---H---I---J
703 \
704 L--M
705 We can also use --ancestry-path=D instead of --ancestry-path which
707 means the same thing when applied to the D..M range but is just
708 more explicit.
709 If we instead are interested in a given topic within this range,
711 and all commits affected by that topic, we may only want to view
712 the subset of D..M which contain that topic in their ancestry path.
713 So, using --ancestry-path=H D..M for example would result in:
714 E
716 \
717 G---H---I---J
718 \
719 L--M
720 Whereas --ancestry-path=K D..M would result in
722 K---------------L--M
724 Before discussing another option, --show-pulls, we need to create a new
726 example history.
727 A common problem users face when looking at simplified history is that
729 a commit they know changed a file somehow does not appear in the file’s
730 simplified history. Let’s demonstrate a new example and show how
731 options such as --full-history and --simplify-merges works in that
732 case:
733 .-A---M-----C--N---O---P
735 / / \ \ \/ / /
736 I B \ R-'`-Z' /
737 \ / \/ /
738 \ / /\ /
739 `---X--' `---Y--'
740 For this example, suppose I created file.txt which was modified by A,
742 B, and X in different ways. The single-parent commits C, Z, and Y do
743 not change file.txt. The merge commit M was created by resolving the
744 merge conflict to include both changes from A and B and hence is not
745 TREESAME to either. The merge commit R, however, was created by
746 ignoring the contents of file.txt at M and taking only the contents of
747 file.txt at X. Hence, R is TREESAME to X but not M. Finally, the
748 natural merge resolution to create N is to take the contents of
749 file.txt at R, so N is TREESAME to R but not C. The merge commits O and
750 P are TREESAME to their first parents, but not to their second parents,
751 Z and Y respectively.
752 When using the default mode, N and R both have a TREESAME parent, so
754 those edges are walked and the others are ignored. The resulting
755 history graph is:
756 I---X
758 When using --full-history, Git walks every edge. This will discover the
760 commits A and B and the merge M, but also will reveal the merge commits
761 O and P. With parent rewriting, the resulting graph is:
762 .-A---M--------N---O---P
764 / / \ \ \/ / /
765 I B \ R-'`--' /
766 \ / \/ /
767 \ / /\ /
768 `---X--' `------'
769 Here, the merge commits O and P contribute extra noise, as they did not
771 actually contribute a change to file.txt. They only merged a topic that
772 was based on an older version of file.txt. This is a common issue in
773 repositories using a workflow where many contributors work in parallel
774 and merge their topic branches along a single trunk: many unrelated
775 merges appear in the --full-history results.
776 When using the --simplify-merges option, the commits O and P disappear
778 from the results. This is because the rewritten second parents of O and
779 P are reachable from their first parents. Those edges are removed and
780 then the commits look like single-parent commits that are TREESAME to
781 their parent. This also happens to the commit N, resulting in a history
782 view as follows:
783 .-A---M--.
785 / / \
786 I B R
787 \ / /
788 \ / /
789 `---X--'
790 In this view, we see all of the important single-parent changes from A,
792 B, and X. We also see the carefully-resolved merge M and the
793 not-so-carefully-resolved merge R. This is usually enough information
794 to determine why the commits A and B "disappeared" from history in the
795 default view. However, there are a few issues with this approach.
796 The first issue is performance. Unlike any previous option, the
798 --simplify-merges option requires walking the entire commit history
799 before returning a single result. This can make the option difficult to
800 use for very large repositories.
801 The second issue is one of auditing. When many contributors are working
803 on the same repository, it is important which merge commits introduced
804 a change into an important branch. The problematic merge R above is not
805 likely to be the merge commit that was used to merge into an important
806 branch. Instead, the merge N was used to merge R and X into the
807 important branch. This commit may have information about why the change
808 X came to override the changes from A and B in its commit message.
809 --show-pulls
811 In addition to the commits shown in the default history, show each
812 merge commit that is not TREESAME to its first parent but is
813 TREESAME to a later parent.
814 When a merge commit is included by --show-pulls, the merge is
816 treated as if it "pulled" the change from another branch. When
817 using --show-pulls on this example (and no other options) the
818 resulting graph is:
819 I---X---R---N
821 Here, the merge commits R and N are included because they pulled
823 the commits X and R into the base branch, respectively. These
824 merges are the reason the commits A and B do not appear in the
825 default history.
826 When --show-pulls is paired with --simplify-merges, the graph
828 includes all of the necessary information:
829 .-A---M--. N
831 / / \ /
832 I B R
833 \ / /
834 \ / /
835 `---X--'
836 Notice that since M is reachable from R, the edge from N to M was
838 simplified away. However, N still appears in the history as an
839 important commit because it "pulled" the change R into the main
840 branch.
841 The --simplify-by-decoration option allows you to view only the big
843 picture of the topology of the history, by omitting commits that are
844 not referenced by tags. Commits are marked as !TREESAME (in other
845 words, kept after history simplification rules described above) if (1)
846 they are referenced by tags, or (2) they change the contents of the
847 paths given on the command line. All other commits are marked as
848 TREESAME (subject to be simplified away).
849 Commit Ordering
851 By default, the commits are shown in reverse chronological order.
852 --date-order
854 Show no parents before all of its children are shown, but otherwise
855 show commits in the commit timestamp order.
856 --author-date-order
858 Show no parents before all of its children are shown, but otherwise
859 show commits in the author timestamp order.
860 --topo-order
862 Show no parents before all of its children are shown, and avoid
863 showing commits on multiple lines of history intermixed.
864 For example, in a commit history like this:
866 ---1----2----4----7
868 \ \
869 3----5----6----8---
870 where the numbers denote the order of commit timestamps, git
872 rev-list and friends with --date-order show the commits in the
873 timestamp order: 8 7 6 5 4 3 2 1.
874 With --topo-order, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5
876 3 1); some older commits are shown before newer ones in order to
877 avoid showing the commits from two parallel development track mixed
878 together.
879 --reverse
881 Output the commits chosen to be shown (see Commit Limiting section
882 above) in reverse order. Cannot be combined with --walk-reflogs.
883 Object Traversal
885 These options are mostly targeted for packing of Git repositories.
886 --no-walk[=(sorted|unsorted)]
888 Only show the given commits, but do not traverse their ancestors.
889 This has no effect if a range is specified. If the argument
890 unsorted is given, the commits are shown in the order they were
891 given on the command line. Otherwise (if sorted or no argument was
892 given), the commits are shown in reverse chronological order by
893 commit time. Cannot be combined with --graph.
894 --do-walk
896 Overrides a previous --no-walk.
897 Commit Formatting
899 --pretty[=<format>], --format=<format>
900 Pretty-print the contents of the commit logs in a given format,
901 where <format> can be one of oneline, short, medium, full, fuller,
902 reference, email, raw, format:<string> and tformat:<string>. When
903 <format> is none of the above, and has %placeholder in it, it acts
904 as if --pretty=tformat:<format> were given.
905 See the "PRETTY FORMATS" section for some additional details for
907 each format. When =<format> part is omitted, it defaults to medium.
908 Note: you can specify the default pretty format in the repository
910 configuration (see git-config(1)).
911 --abbrev-commit
913 Instead of showing the full 40-byte hexadecimal commit object name,
914 show a prefix that names the object uniquely. "--abbrev=<n>" (which
915 also modifies diff output, if it is displayed) option can be used
916 to specify the minimum length of the prefix.
917 This should make "--pretty=oneline" a whole lot more readable for
919 people using 80-column terminals.
920 --no-abbrev-commit
922 Show the full 40-byte hexadecimal commit object name. This negates
923 --abbrev-commit, either explicit or implied by other options such
924 as "--oneline". It also overrides the log.abbrevCommit variable.
925 --oneline
927 This is a shorthand for "--pretty=oneline --abbrev-commit" used
928 together.
929 --encoding=<encoding>
931 Commit objects record the character encoding used for the log
932 message in their encoding header; this option can be used to tell
933 the command to re-code the commit log message in the encoding
934 preferred by the user. For non plumbing commands this defaults to
935 UTF-8. Note that if an object claims to be encoded in X and we are
936 outputting in X, we will output the object verbatim; this means
937 that invalid sequences in the original commit may be copied to the
938 output. Likewise, if iconv(3) fails to convert the commit, we will
939 quietly output the original object verbatim.
940 --expand-tabs=<n>, --expand-tabs, --no-expand-tabs
942 Perform a tab expansion (replace each tab with enough spaces to
943 fill to the next display column that is a multiple of <n>) in the
944 log message before showing it in the output. --expand-tabs is a
945 short-hand for --expand-tabs=8, and --no-expand-tabs is a
946 short-hand for --expand-tabs=0, which disables tab expansion.
947 By default, tabs are expanded in pretty formats that indent the log
949 message by 4 spaces (i.e. medium, which is the default, full, and
950 fuller).
951 --notes[=<ref>]
953 Show the notes (see git-notes(1)) that annotate the commit, when
954 showing the commit log message. This is the default for git log,
955 git show and git whatchanged commands when there is no --pretty,
956 --format, or --oneline option given on the command line.
957 By default, the notes shown are from the notes refs listed in the
959 core.notesRef and notes.displayRef variables (or corresponding
960 environment overrides). See git-config(1) for more details.
961 With an optional <ref> argument, use the ref to find the notes to
963 display. The ref can specify the full refname when it begins with
964 refs/notes/; when it begins with notes/, refs/ and otherwise
965 refs/notes/ is prefixed to form the full name of the ref.
966 Multiple --notes options can be combined to control which notes are
968 being displayed. Examples: "--notes=foo" will show only notes from
969 "refs/notes/foo"; "--notes=foo --notes" will show both notes from
970 "refs/notes/foo" and from the default notes ref(s).
971 --no-notes
973 Do not show notes. This negates the above --notes option, by
974 resetting the list of notes refs from which notes are shown.
975 Options are parsed in the order given on the command line, so e.g.
976 "--notes --notes=foo --no-notes --notes=bar" will only show notes
977 from "refs/notes/bar".
978 --show-notes-by-default
980 Show the default notes unless options for displaying specific notes
981 are given.
982 --show-notes[=<ref>], --[no-]standard-notes
984 These options are deprecated. Use the above --notes/--no-notes
985 options instead.
986 --show-signature
988 Check the validity of a signed commit object by passing the
989 signature to gpg --verify and show the output.
990 --relative-date
992 Synonym for --date=relative.
993 --date=<format>
995 Only takes effect for dates shown in human-readable format, such as
996 when using --pretty. log.date config variable sets a default value
997 for the log command’s --date option. By default, dates are shown in
998 the original time zone (either committer’s or author’s). If -local
999 is appended to the format (e.g., iso-local), the user’s local time
1000 zone is used instead.
1001 --date=relative shows dates relative to the current time, e.g. “2
1003 hours ago”. The -local option has no effect for --date=relative.
1004 --date=local is an alias for --date=default-local.
1006 --date=iso (or --date=iso8601) shows timestamps in a ISO 8601-like
1008 format. The differences to the strict ISO 8601 format are:
1009 • a space instead of the T date/time delimiter
1011 • a space between time and time zone
1013 • no colon between hours and minutes of the time zone
1015 --date=iso-strict (or --date=iso8601-strict) shows timestamps in
1017 strict ISO 8601 format.
1018 --date=rfc (or --date=rfc2822) shows timestamps in RFC 2822 format,
1020 often found in email messages.
1021 --date=short shows only the date, but not the time, in YYYY-MM-DD
1023 format.
1024 --date=raw shows the date as seconds since the epoch (1970-01-01
1026 00:00:00 UTC), followed by a space, and then the timezone as an
1027 offset from UTC (a + or - with four digits; the first two are
1028 hours, and the second two are minutes). I.e., as if the timestamp
1029 were formatted with strftime("%s %z")). Note that the -local option
1030 does not affect the seconds-since-epoch value (which is always
1031 measured in UTC), but does switch the accompanying timezone value.
1032 --date=human shows the timezone if the timezone does not match the
1034 current time-zone, and doesn’t print the whole date if that matches
1035 (ie skip printing year for dates that are "this year", but also
1036 skip the whole date itself if it’s in the last few days and we can
1037 just say what weekday it was). For older dates the hour and minute
1038 is also omitted.
1039 --date=unix shows the date as a Unix epoch timestamp (seconds since
1041 1970). As with --raw, this is always in UTC and therefore -local
1042 has no effect.
1043 --date=format:... feeds the format ... to your system strftime,
1045 except for %s, %z, and %Z, which are handled internally. Use
1046 --date=format:%c to show the date in your system locale’s preferred
1047 format. See the strftime manual for a complete list of format
1048 placeholders. When using -local, the correct syntax is
1049 --date=format-local:....
1050 --date=default is the default format, and is based on ctime(3)
1052 output. It shows a single line with three-letter day of the week,
1053 three-letter month, day-of-month, hour-minute-seconds in "HH:MM:SS"
1054 format, followed by 4-digit year, plus timezone information, unless
1055 the local time zone is used, e.g. Thu Jan 1 00:00:00 1970 +0000.
1056 --parents
1058 Print also the parents of the commit (in the form "commit parent...
1059 "). Also enables parent rewriting, see History Simplification
1060 above.
1061 --children
1063 Print also the children of the commit (in the form "commit child...
1064 "). Also enables parent rewriting, see History Simplification
1065 above.
1066 --left-right
1068 Mark which side of a symmetric difference a commit is reachable
1069 from. Commits from the left side are prefixed with < and those from
1070 the right with >. If combined with --boundary, those commits are
1071 prefixed with -.
1072 For example, if you have this topology:
1074 y---b---b branch B
1076 / \ /
1077 / .
1078 / / \
1079 o---x---a---a branch A
1080 you would get an output like this:
1082 $ git rev-list --left-right --boundary --pretty=oneline A...B
1084 >bbbbbbb... 3rd on b
1086 >bbbbbbb... 2nd on b
1087 <aaaaaaa... 3rd on a
1088 <aaaaaaa... 2nd on a
1089 -yyyyyyy... 1st on b
1090 -xxxxxxx... 1st on a
1091 --graph
1093 Draw a text-based graphical representation of the commit history on
1094 the left hand side of the output. This may cause extra lines to be
1095 printed in between commits, in order for the graph history to be
1096 drawn properly. Cannot be combined with --no-walk.
1097 This enables parent rewriting, see History Simplification above.
1099 This implies the --topo-order option by default, but the
1101 --date-order option may also be specified.
1102 --show-linear-break[=<barrier>]
1104 When --graph is not used, all history branches are flattened which
1105 can make it hard to see that the two consecutive commits do not
1106 belong to a linear branch. This option puts a barrier in between
1107 them in that case. If <barrier> is specified, it is the string that
1108 will be shown instead of the default one.
1109
1111 If the commit is a merge, and if the pretty-format is not oneline,
1112 email or raw, an additional line is inserted before the Author: line.
1113 This line begins with "Merge: " and the hashes of ancestral commits are
1114 printed, separated by spaces. Note that the listed commits may not
1115 necessarily be the list of the direct parent commits if you have
1116 limited your view of history: for example, if you are only interested
1117 in changes related to a certain directory or file.
1118 There are several built-in formats, and you can define additional
1120 formats by setting a pretty.<name> config option to either another
1121 format name, or a format: string, as described below (see git-
1122 config(1)). Here are the details of the built-in formats:
1123 • oneline
1125 <hash> <title-line>
1127 This is designed to be as compact as possible.
1129 • short
1131 commit <hash>
1133 Author: <author>
1134 <title-line>
1136 • medium
1138 commit <hash>
1140 Author: <author>
1141 Date: <author-date>
1142 <title-line>
1144 <full-commit-message>
1146 • full
1148 commit <hash>
1150 Author: <author>
1151 Commit: <committer>
1152 <title-line>
1154 <full-commit-message>
1156 • fuller
1158 commit <hash>
1160 Author: <author>
1161 AuthorDate: <author-date>
1162 Commit: <committer>
1163 CommitDate: <committer-date>
1164 <title-line>
1166 <full-commit-message>
1168 • reference
1170 <abbrev-hash> (<title-line>, <short-author-date>)
1172 This format is used to refer to another commit in a commit message
1174 and is the same as --pretty='format:%C(auto)%h (%s, %ad)'. By
1175 default, the date is formatted with --date=short unless another
1176 --date option is explicitly specified. As with any format: with
1177 format placeholders, its output is not affected by other options
1178 like --decorate and --walk-reflogs.
1179 • email
1181 From <hash> <date>
1183 From: <author>
1184 Date: <author-date>
1185 Subject: [PATCH] <title-line>
1186 <full-commit-message>
1188 • mboxrd
1190 Like email, but lines in the commit message starting with "From "
1192 (preceded by zero or more ">") are quoted with ">" so they aren’t
1193 confused as starting a new commit.
1194 • raw
1196 The raw format shows the entire commit exactly as stored in the
1198 commit object. Notably, the hashes are displayed in full,
1199 regardless of whether --abbrev or --no-abbrev are used, and parents
1200 information show the true parent commits, without taking grafts or
1201 history simplification into account. Note that this format affects
1202 the way commits are displayed, but not the way the diff is shown
1203 e.g. with git log --raw. To get full object names in a raw diff
1204 format, use --no-abbrev.
1205 • format:<format-string>
1207 The format:<format-string> format allows you to specify which
1209 information you want to show. It works a little bit like printf
1210 format, with the notable exception that you get a newline with %n
1211 instead of \n.
1212 E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
1214 would show something like this:
1215 The author of fe6e0ee was Junio C Hamano, 23 hours ago
1217 The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
1218 The placeholders are:
1220 • Placeholders that expand to a single literal character:
1222 %n
1224 newline
1225 %%
1227 a raw %
1228 %x00
1230 %x followed by two hexadecimal digits is replaced with a
1231 byte with the hexadecimal digits' value (we will call this
1232 "literal formatting code" in the rest of this document).
1233 • Placeholders that affect formatting of later placeholders:
1235 %Cred
1237 switch color to red
1238 %Cgreen
1240 switch color to green
1241 %Cblue
1243 switch color to blue
1244 %Creset
1246 reset color
1247 %C(...)
1249 color specification, as described under Values in the
1250 "CONFIGURATION FILE" section of git-config(1). By default,
1251 colors are shown only when enabled for log output (by
1252 color.diff, color.ui, or --color, and respecting the auto
1253 settings of the former if we are going to a terminal).
1254 %C(auto,...) is accepted as a historical synonym for the
1255 default (e.g., %C(auto,red)). Specifying %C(always,...)
1256 will show the colors even when color is not otherwise
1257 enabled (though consider just using --color=always to
1258 enable color for the whole output, including this format
1259 and anything else git might color). auto alone (i.e.
1260 %C(auto)) will turn on auto coloring on the next
1261 placeholders until the color is switched again.
1262 %m
1264 left (<), right (>) or boundary (-) mark
1265 %w([<w>[,<i1>[,<i2>]]])
1267 switch line wrapping, like the -w option of git-
1268 shortlog(1).
1269 %<( <N> [,trunc|ltrunc|mtrunc])
1271 make the next placeholder take at least N column widths,
1272 padding spaces on the right if necessary. Optionally
1273 truncate (with ellipsis ..) at the left (ltrunc) ..ft, the
1274 middle (mtrunc) mi..le, or the end (trunc) rig.., if the
1275 output is longer than N columns. Note 1: that truncating
1276 only works correctly with N >= 2. Note 2: spaces around the
1277 N and M (see below) values are optional. Note 3: Emojis and
1278 other wide characters will take two display columns, which
1279 may over-run column boundaries. Note 4: decomposed
1280 character combining marks may be misplaced at padding
1281 boundaries.
1282 %<|( <M> )
1284 make the next placeholder take at least until Mth display
1285 column, padding spaces on the right if necessary. Use
1286 negative M values for column positions measured from the
1287 right hand edge of the terminal window.
1288 %>( <N> ), %>|( <M> )
1290 similar to %<( <N> ), %<|( <M> ) respectively, but padding
1291 spaces on the left
1292 %>>( <N> ), %>>|( <M> )
1294 similar to %>( <N> ), %>|( <M> ) respectively, except that
1295 if the next placeholder takes more spaces than given and
1296 there are spaces on its left, use those spaces
1297 %><( <N> ), %><|( <M> )
1299 similar to %<( <N> ), %<|( <M> ) respectively, but padding
1300 both sides (i.e. the text is centered)
1301 • Placeholders that expand to information extracted from the
1303 commit:
1304 %H
1306 commit hash
1307 %h
1309 abbreviated commit hash
1310 %T
1312 tree hash
1313 %t
1315 abbreviated tree hash
1316 %P
1318 parent hashes
1319 %p
1321 abbreviated parent hashes
1322 %an
1324 author name
1325 %aN
1327 author name (respecting .mailmap, see git-shortlog(1) or
1328 git-blame(1))
1329 %ae
1331 author email
1332 %aE
1334 author email (respecting .mailmap, see git-shortlog(1) or
1335 git-blame(1))
1336 %al
1338 author email local-part (the part before the @ sign)
1339 %aL
1341 author local-part (see %al) respecting .mailmap, see git-
1342 shortlog(1) or git-blame(1))
1343 %ad
1345 author date (format respects --date= option)
1346 %aD
1348 author date, RFC2822 style
1349 %ar
1351 author date, relative
1352 %at
1354 author date, UNIX timestamp
1355 %ai
1357 author date, ISO 8601-like format
1358 %aI
1360 author date, strict ISO 8601 format
1361 %as
1363 author date, short format (YYYY-MM-DD)
1364 %ah
1366 author date, human style (like the --date=human option of
1367 git-rev-list(1))
1368 %cn
1370 committer name
1371 %cN
1373 committer name (respecting .mailmap, see git-shortlog(1) or
1374 git-blame(1))
1375 %ce
1377 committer email
1378 %cE
1380 committer email (respecting .mailmap, see git-shortlog(1)
1381 or git-blame(1))
1382 %cl
1384 committer email local-part (the part before the @ sign)
1385 %cL
1387 committer local-part (see %cl) respecting .mailmap, see
1388 git-shortlog(1) or git-blame(1))
1389 %cd
1391 committer date (format respects --date= option)
1392 %cD
1394 committer date, RFC2822 style
1395 %cr
1397 committer date, relative
1398 %ct
1400 committer date, UNIX timestamp
1401 %ci
1403 committer date, ISO 8601-like format
1404 %cI
1406 committer date, strict ISO 8601 format
1407 %cs
1409 committer date, short format (YYYY-MM-DD)
1410 %ch
1412 committer date, human style (like the --date=human option
1413 of git-rev-list(1))
1414 %d
1416 ref names, like the --decorate option of git-log(1)
1417 %D
1419 ref names without the " (", ")" wrapping.
1420 %(decorate[:<options>])
1422 ref names with custom decorations. The decorate string may
1423 be followed by a colon and zero or more comma-separated
1424 options. Option values may contain literal formatting
1425 codes. These must be used for commas (%x2C) and closing
1426 parentheses (%x29), due to their role in the option syntax.
1427 • prefix=<value>: Shown before the list of ref names.
1429 Defaults to " (".
1430 • suffix=<value>: Shown after the list of ref names.
1432 Defaults to ")".
1433 • separator=<value>: Shown between ref names. Defaults to
1435 ", ".
1436 • pointer=<value>: Shown between HEAD and the branch it
1438 points to, if any. Defaults to " -> ".
1439 • tag=<value>: Shown before tag names. Defaults to
1441 "tag: ".
1442 For example, to produce decorations with no wrapping or tag
1444 annotations, and spaces as separators:
1445 + %(decorate:prefix=,suffix=,tag=,separator= )
1447 %(describe[:<options>])
1449 human-readable name, like git-describe(1); empty string for
1450 undescribable commits. The describe string may be followed by a
1451 colon and zero or more comma-separated options. Descriptions
1452 can be inconsistent when tags are added or removed at the same
1453 time.
1454 • tags[=<bool-value>]: Instead of only considering annotated
1456 tags, consider lightweight tags as well.
1457 • abbrev=<number>: Instead of using the default number of
1459 hexadecimal digits (which will vary according to the number
1460 of objects in the repository with a default of 7) of the
1461 abbreviated object name, use <number> digits, or as many
1462 digits as needed to form a unique object name.
1463 • match=<pattern>: Only consider tags matching the given
1465 glob(7) pattern, excluding the "refs/tags/" prefix.
1466 • exclude=<pattern>: Do not consider tags matching the given
1468 glob(7) pattern, excluding the "refs/tags/" prefix.
1469 %S
1471 ref name given on the command line by which the commit was
1472 reached (like git log --source), only works with git log
1473 %e
1475 encoding
1476 %s
1478 subject
1479 %f
1481 sanitized subject line, suitable for a filename
1482 %b
1484 body
1485 %B
1487 raw body (unwrapped subject and body)
1488 %N
1490 commit notes
1491 %GG
1493 raw verification message from GPG for a signed commit
1494 %G?
1496 show "G" for a good (valid) signature, "B" for a bad signature,
1497 "U" for a good signature with unknown validity, "X" for a good
1498 signature that has expired, "Y" for a good signature made by an
1499 expired key, "R" for a good signature made by a revoked key,
1500 "E" if the signature cannot be checked (e.g. missing key) and
1501 "N" for no signature
1502 %GS
1504 show the name of the signer for a signed commit
1505 %GK
1507 show the key used to sign a signed commit
1508 %GF
1510 show the fingerprint of the key used to sign a signed commit
1511 %GP
1513 show the fingerprint of the primary key whose subkey was used
1514 to sign a signed commit
1515 %GT
1517 show the trust level for the key used to sign a signed commit
1518 %gD
1520 reflog selector, e.g., refs/stash@{1} or refs/stash@{2 minutes
1521 ago}; the format follows the rules described for the -g option.
1522 The portion before the @ is the refname as given on the command
1523 line (so git log -g refs/heads/master would yield
1524 refs/heads/master@{0}).
1525 %gd
1527 shortened reflog selector; same as %gD, but the refname portion
1528 is shortened for human readability (so refs/heads/master
1529 becomes just master).
1530 %gn
1532 reflog identity name
1533 %gN
1535 reflog identity name (respecting .mailmap, see git-shortlog(1)
1536 or git-blame(1))
1537 %ge
1539 reflog identity email
1540 %gE
1542 reflog identity email (respecting .mailmap, see git-shortlog(1)
1543 or git-blame(1))
1544 %gs
1546 reflog subject
1547 %(trailers[:<options>])
1549 display the trailers of the body as interpreted by git-
1550 interpret-trailers(1). The trailers string may be followed by a
1551 colon and zero or more comma-separated options. If any option
1552 is provided multiple times, the last occurrence wins.
1553 • key=<key>: only show trailers with specified <key>.
1555 Matching is done case-insensitively and trailing colon is
1556 optional. If option is given multiple times trailer lines
1557 matching any of the keys are shown. This option
1558 automatically enables the only option so that non-trailer
1559 lines in the trailer block are hidden. If that is not
1560 desired it can be disabled with only=false. E.g.,
1561 %(trailers:key=Reviewed-by) shows trailer lines with key
1562 Reviewed-by.
1563 • only[=<bool>]: select whether non-trailer lines from the
1565 trailer block should be included.
1566 • separator=<sep>: specify a separator inserted between
1568 trailer lines. When this option is not given each trailer
1569 line is terminated with a line feed character. The string
1570 <sep> may contain the literal formatting codes described
1571 above. To use comma as separator one must use %x2C as it
1572 would otherwise be parsed as next option. E.g.,
1573 %(trailers:key=Ticket,separator=%x2C ) shows all trailer
1574 lines whose key is "Ticket" separated by a comma and a
1575 space.
1576 • unfold[=<bool>]: make it behave as if interpret-trailer’s
1578 --unfold option was given. E.g.,
1579 %(trailers:only,unfold=true) unfolds and shows all trailer
1580 lines.
1581 • keyonly[=<bool>]: only show the key part of the trailer.
1583 • valueonly[=<bool>]: only show the value part of the
1585 trailer.
1586 • key_value_separator=<sep>: specify a separator inserted
1588 between trailer lines. When this option is not given each
1589 trailer key-value pair is separated by ": ". Otherwise it
1590 shares the same semantics as separator=<sep> above.
1591 Note
1593 Some placeholders may depend on other options given to the revision
1594 traversal engine. For example, the %g* reflog options will insert
1595 an empty string unless we are traversing reflog entries (e.g., by
1596 git log -g). The %d and %D placeholders will use the "short"
1597 decoration format if --decorate was not already provided on the
1598 command line.
1599 The boolean options accept an optional value [=<bool-value>]. The
1601 values true, false, on, off etc. are all accepted. See the "boolean"
1602 sub-section in "EXAMPLES" in git-config(1). If a boolean option is
1603 given with no value, it’s enabled.
1604 If you add a + (plus sign) after % of a placeholder, a line-feed is
1606 inserted immediately before the expansion if and only if the
1607 placeholder expands to a non-empty string.
1608 If you add a - (minus sign) after % of a placeholder, all consecutive
1610 line-feeds immediately preceding the expansion are deleted if and only
1611 if the placeholder expands to an empty string.
1612 If you add a ` ` (space) after % of a placeholder, a space is inserted
1614 immediately before the expansion if and only if the placeholder expands
1615 to a non-empty string.
1616 • tformat:
1618 The tformat: format works exactly like format:, except that it
1620 provides "terminator" semantics instead of "separator" semantics.
1621 In other words, each commit has the message terminator character
1622 (usually a newline) appended, rather than a separator placed
1623 between entries. This means that the final entry of a single-line
1624 format will be properly terminated with a new line, just as the
1625 "oneline" format does. For example:
1626 $ git log -2 --pretty=format:%h 4da45bef \
1628 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
1629 4da45be
1630 7134973 -- NO NEWLINE
1631 $ git log -2 --pretty=tformat:%h 4da45bef \
1633 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
1634 4da45be
1635 7134973
1636 In addition, any unrecognized string that has a % in it is
1638 interpreted as if it has tformat: in front of it. For example,
1639 these two are equivalent:
1640 $ git log -2 --pretty=tformat:%h 4da45bef
1642 $ git log -2 --pretty=%h 4da45bef
1643
1645 By default, git log does not generate any diff output. The options
1646 below can be used to show the changes made by each commit.
1647 Note that unless one of --diff-merges variants (including short -m, -c,
1649 --cc, and --dd options) is explicitly given, merge commits will not
1650 show a diff, even if a diff format like --patch is selected, nor will
1651 they match search options like -S. The exception is when --first-parent
1652 is in use, in which case first-parent is the default format for merge
1653 commits.
1654 -p, -u, --patch
1656 Generate patch (see the section called “GENERATING PATCH TEXT WITH
1657 -P”).
1658 -s, --no-patch
1660 Suppress all output from the diff machinery. Useful for commands
1661 like git show that show the patch by default to squelch their
1662 output, or to cancel the effect of options like --patch, --stat
1663 earlier on the command line in an alias.
1664 -m
1666 Show diffs for merge commits in the default format. This is similar
1667 to --diff-merges=on, except -m will produce no output unless -p is
1668 given as well.
1669 -c
1671 Produce combined diff output for merge commits. Shortcut for
1672 --diff-merges=combined -p.
1673 --cc
1675 Produce dense combined diff output for merge commits. Shortcut for
1676 --diff-merges=dense-combined -p.
1677 --dd
1679 Produce diff with respect to first parent for both merge and
1680 regular commits. Shortcut for --diff-merges=first-parent -p.
1681 --remerge-diff
1683 Produce remerge-diff output for merge commits. Shortcut for
1684 --diff-merges=remerge -p.
1685 --no-diff-merges
1687 Synonym for --diff-merges=off.
1688 --diff-merges=<format>
1690 Specify diff format to be used for merge commits. Default is `off`
1691 unless --first-parent is in use, in which case first-parent is the
1692 default.
1693 The following formats are supported:
1695 off, none
1697 Disable output of diffs for merge commits. Useful to override
1698 implied value.
1699 on, m
1701 Make diff output for merge commits to be shown in the default
1702 format. The default format can be changed using log.diffMerges
1703 configuration variable, whose default value is separate.
1704 first-parent, 1
1706 Show full diff with respect to first parent. This is the same
1707 format as --patch produces for non-merge commits.
1708 separate
1710 Show full diff with respect to each of parents. Separate log
1711 entry and diff is generated for each parent.
1712 combined, c
1714 Show differences from each of the parents to the merge result
1715 simultaneously instead of showing pairwise diff between a
1716 parent and the result one at a time. Furthermore, it lists only
1717 files which were modified from all parents.
1718 dense-combined, cc
1720 Further compress output produced by --diff-merges=combined by
1721 omitting uninteresting hunks whose contents in the parents have
1722 only two variants and the merge result picks one of them
1723 without modification.
1724 remerge, r
1726 Remerge two-parent merge commits to create a temporary tree
1727 object—potentially containing files with conflict markers and
1728 such. A diff is then shown between that temporary tree and the
1729 actual merge commit.
1730 The output emitted when this option is used is subject to
1732 change, and so is its interaction with other options (unless
1733 explicitly documented).
1734 --combined-all-paths
1736 This flag causes combined diffs (used for merge commits) to list
1737 the name of the file from all parents. It thus only has effect when
1738 --diff-merges=[dense-]combined is in use, and is likely only useful
1739 if filename changes are detected (i.e. when either rename or copy
1740 detection have been requested).
1741 -U<n>, --unified=<n>
1743 Generate diffs with <n> lines of context instead of the usual
1744 three. Implies --patch.
1745 --output=<file>
1747 Output to a specific file instead of stdout.
1748 --output-indicator-new=<char>, --output-indicator-old=<char>,
1750 --output-indicator-context=<char>
1751 Specify the character used to indicate new, old or context lines in
1752 the generated patch. Normally they are +, - and ' ' respectively.
1753 --raw
1755 For each commit, show a summary of changes using the raw diff
1756 format. See the "RAW OUTPUT FORMAT" section of git-diff(1). This is
1757 different from showing the log itself in raw format, which you can
1758 achieve with --format=raw.
1759 --patch-with-raw
1761 Synonym for -p --raw.
1762 -t
1764 Show the tree objects in the diff output.
1765 --indent-heuristic
1767 Enable the heuristic that shifts diff hunk boundaries to make
1768 patches easier to read. This is the default.
1769 --no-indent-heuristic
1771 Disable the indent heuristic.
1772 --minimal
1774 Spend extra time to make sure the smallest possible diff is
1775 produced.
1776 --patience
1778 Generate a diff using the "patience diff" algorithm.
1779 --histogram
1781 Generate a diff using the "histogram diff" algorithm.
1782 --anchored=<text>
1784 Generate a diff using the "anchored diff" algorithm.
1785 This option may be specified more than once.
1787 If a line exists in both the source and destination, exists only
1789 once, and starts with this text, this algorithm attempts to prevent
1790 it from appearing as a deletion or addition in the output. It uses
1791 the "patience diff" algorithm internally.
1792 --diff-algorithm={patience|minimal|histogram|myers}
1794 Choose a diff algorithm. The variants are as follows:
1795 default, myers
1797 The basic greedy diff algorithm. Currently, this is the
1798 default.
1799 minimal
1801 Spend extra time to make sure the smallest possible diff is
1802 produced.
1803 patience
1805 Use "patience diff" algorithm when generating patches.
1806 histogram
1808 This algorithm extends the patience algorithm to "support
1809 low-occurrence common elements".
1810 For instance, if you configured the diff.algorithm variable to a
1812 non-default value and want to use the default one, then you have to
1813 use --diff-algorithm=default option.
1814 --stat[=<width>[,<name-width>[,<count>]]]
1816 Generate a diffstat. By default, as much space as necessary will be
1817 used for the filename part, and the rest for the graph part.
1818 Maximum width defaults to terminal width, or 80 columns if not
1819 connected to a terminal, and can be overridden by <width>. The
1820 width of the filename part can be limited by giving another width
1821 <name-width> after a comma or by setting
1822 diff.statNameWidth=<width>. The width of the graph part can be
1823 limited by using --stat-graph-width=<width> or by setting
1824 diff.statGraphWidth=<width>. Using --stat or --stat-graph-width
1825 affects all commands generating a stat graph, while setting
1826 diff.statNameWidth or diff.statGraphWidth does not affect git
1827 format-patch. By giving a third parameter <count>, you can limit
1828 the output to the first <count> lines, followed by ... if there
1829 are more.
1830 These parameters can also be set individually with
1832 --stat-width=<width>, --stat-name-width=<name-width> and
1833 --stat-count=<count>.
1834 --compact-summary
1836 Output a condensed summary of extended header information such as
1837 file creations or deletions ("new" or "gone", optionally "+l" if
1838 it’s a symlink) and mode changes ("+x" or "-x" for adding or
1839 removing executable bit respectively) in diffstat. The information
1840 is put between the filename part and the graph part. Implies
1841 --stat.
1842 --numstat
1844 Similar to --stat, but shows number of added and deleted lines in
1845 decimal notation and pathname without abbreviation, to make it more
1846 machine friendly. For binary files, outputs two - instead of saying
1847 0 0.
1848 --shortstat
1850 Output only the last line of the --stat format containing total
1851 number of modified files, as well as number of added and deleted
1852 lines.
1853 -X[<param1,param2,...>], --dirstat[=<param1,param2,...>]
1855 Output the distribution of relative amount of changes for each
1856 sub-directory. The behavior of --dirstat can be customized by
1857 passing it a comma separated list of parameters. The defaults are
1858 controlled by the diff.dirstat configuration variable (see git-
1859 config(1)). The following parameters are available:
1860 changes
1862 Compute the dirstat numbers by counting the lines that have
1863 been removed from the source, or added to the destination. This
1864 ignores the amount of pure code movements within a file. In
1865 other words, rearranging lines in a file is not counted as much
1866 as other changes. This is the default behavior when no
1867 parameter is given.
1868 lines
1870 Compute the dirstat numbers by doing the regular line-based
1871 diff analysis, and summing the removed/added line counts. (For
1872 binary files, count 64-byte chunks instead, since binary files
1873 have no natural concept of lines). This is a more expensive
1874 --dirstat behavior than the changes behavior, but it does count
1875 rearranged lines within a file as much as other changes. The
1876 resulting output is consistent with what you get from the other
1877 --*stat options.
1878 files
1880 Compute the dirstat numbers by counting the number of files
1881 changed. Each changed file counts equally in the dirstat
1882 analysis. This is the computationally cheapest --dirstat
1883 behavior, since it does not have to look at the file contents
1884 at all.
1885 cumulative
1887 Count changes in a child directory for the parent directory as
1888 well. Note that when using cumulative, the sum of the
1889 percentages reported may exceed 100%. The default
1890 (non-cumulative) behavior can be specified with the
1891 noncumulative parameter.
1892 <limit>
1894 An integer parameter specifies a cut-off percent (3% by
1895 default). Directories contributing less than this percentage of
1896 the changes are not shown in the output.
1897 Example: The following will count changed files, while ignoring
1899 directories with less than 10% of the total amount of changed
1900 files, and accumulating child directory counts in the parent
1901 directories: --dirstat=files,10,cumulative.
1902 --cumulative
1904 Synonym for --dirstat=cumulative
1905 --dirstat-by-file[=<param1,param2>...]
1907 Synonym for --dirstat=files,param1,param2...
1908 --summary
1910 Output a condensed summary of extended header information such as
1911 creations, renames and mode changes.
1912 --patch-with-stat
1914 Synonym for -p --stat.
1915 -z
1917 Separate the commits with NULs instead of newlines.
1918 Also, when --raw or --numstat has been given, do not munge
1920 pathnames and use NULs as output field terminators.
1921 Without this option, pathnames with "unusual" characters are quoted
1923 as explained for the configuration variable core.quotePath (see
1924 git-config(1)).
1925 --name-only
1927 Show only names of changed files. The file names are often encoded
1928 in UTF-8. For more information see the discussion about encoding in
1929 the git-log(1) manual page.
1930 --name-status
1932 Show only names and status of changed files. See the description of
1933 the --diff-filter option on what the status letters mean. Just like
1934 --name-only the file names are often encoded in UTF-8.
1935 --submodule[=<format>]
1937 Specify how differences in submodules are shown. When specifying
1938 --submodule=short the short format is used. This format just shows
1939 the names of the commits at the beginning and end of the range.
1940 When --submodule or --submodule=log is specified, the log format is
1941 used. This format lists the commits in the range like git-
1942 submodule(1) summary does. When --submodule=diff is specified, the
1943 diff format is used. This format shows an inline diff of the
1944 changes in the submodule contents between the commit range.
1945 Defaults to diff.submodule or the short format if the config option
1946 is unset.
1947 --color[=<when>]
1949 Show colored diff. --color (i.e. without =<when>) is the same as
1950 --color=always. <when> can be one of always, never, or auto.
1951 --no-color
1953 Turn off colored diff. It is the same as --color=never.
1954 --color-moved[=<mode>]
1956 Moved lines of code are colored differently. The <mode> defaults to
1957 no if the option is not given and to zebra if the option with no
1958 mode is given. The mode must be one of:
1959 no
1961 Moved lines are not highlighted.
1962 default
1964 Is a synonym for zebra. This may change to a more sensible mode
1965 in the future.
1966 plain
1968 Any line that is added in one location and was removed in
1969 another location will be colored with color.diff.newMoved.
1970 Similarly color.diff.oldMoved will be used for removed lines
1971 that are added somewhere else in the diff. This mode picks up
1972 any moved line, but it is not very useful in a review to
1973 determine if a block of code was moved without permutation.
1974 blocks
1976 Blocks of moved text of at least 20 alphanumeric characters are
1977 detected greedily. The detected blocks are painted using either
1978 the color.diff.{old,new}Moved color. Adjacent blocks cannot be
1979 told apart.
1980 zebra
1982 Blocks of moved text are detected as in blocks mode. The blocks
1983 are painted using either the color.diff.{old,new}Moved color or
1984 color.diff.{old,new}MovedAlternative. The change between the
1985 two colors indicates that a new block was detected.
1986 dimmed-zebra
1988 Similar to zebra, but additional dimming of uninteresting parts
1989 of moved code is performed. The bordering lines of two adjacent
1990 blocks are considered interesting, the rest is uninteresting.
1991 dimmed_zebra is a deprecated synonym.
1992 --no-color-moved
1994 Turn off move detection. This can be used to override configuration
1995 settings. It is the same as --color-moved=no.
1996 --color-moved-ws=<modes>
1998 This configures how whitespace is ignored when performing the move
1999 detection for --color-moved. These modes can be given as a comma
2000 separated list:
2001 no
2003 Do not ignore whitespace when performing move detection.
2004 ignore-space-at-eol
2006 Ignore changes in whitespace at EOL.
2007 ignore-space-change
2009 Ignore changes in amount of whitespace. This ignores whitespace
2010 at line end, and considers all other sequences of one or more
2011 whitespace characters to be equivalent.
2012 ignore-all-space
2014 Ignore whitespace when comparing lines. This ignores
2015 differences even if one line has whitespace where the other
2016 line has none.
2017 allow-indentation-change
2019 Initially ignore any whitespace in the move detection, then
2020 group the moved code blocks only into a block if the change in
2021 whitespace is the same per line. This is incompatible with the
2022 other modes.
2023 --no-color-moved-ws
2025 Do not ignore whitespace when performing move detection. This can
2026 be used to override configuration settings. It is the same as
2027 --color-moved-ws=no.
2028 --word-diff[=<mode>]
2030 Show a word diff, using the <mode> to delimit changed words. By
2031 default, words are delimited by whitespace; see --word-diff-regex
2032 below. The <mode> defaults to plain, and must be one of:
2033 color
2035 Highlight changed words using only colors. Implies --color.
2036 plain
2038 Show words as [-removed-] and {+added+}. Makes no attempts to
2039 escape the delimiters if they appear in the input, so the
2040 output may be ambiguous.
2041 porcelain
2043 Use a special line-based format intended for script
2044 consumption. Added/removed/unchanged runs are printed in the
2045 usual unified diff format, starting with a +/-/` ` character at
2046 the beginning of the line and extending to the end of the line.
2047 Newlines in the input are represented by a tilde ~ on a line of
2048 its own.
2049 none
2051 Disable word diff again.
2052 Note that despite the name of the first mode, color is used to
2054 highlight the changed parts in all modes if enabled.
2055 --word-diff-regex=<regex>
2057 Use <regex> to decide what a word is, instead of considering runs
2058 of non-whitespace to be a word. Also implies --word-diff unless it
2059 was already enabled.
2060 Every non-overlapping match of the <regex> is considered a word.
2062 Anything between these matches is considered whitespace and
2063 ignored(!) for the purposes of finding differences. You may want to
2064 append |[^[:space:]] to your regular expression to make sure that
2065 it matches all non-whitespace characters. A match that contains a
2066 newline is silently truncated(!) at the newline.
2067 For example, --word-diff-regex=. will treat each character as a
2069 word and, correspondingly, show differences character by character.
2070 The regex can also be set via a diff driver or configuration
2072 option, see gitattributes(5) or git-config(1). Giving it explicitly
2073 overrides any diff driver or configuration setting. Diff drivers
2074 override configuration settings.
2075 --color-words[=<regex>]
2077 Equivalent to --word-diff=color plus (if a regex was specified)
2078 --word-diff-regex=<regex>.
2079 --no-renames
2081 Turn off rename detection, even when the configuration file gives
2082 the default to do so.
2083 --[no-]rename-empty
2085 Whether to use empty blobs as rename source.
2086 --check
2088 Warn if changes introduce conflict markers or whitespace errors.
2089 What are considered whitespace errors is controlled by
2090 core.whitespace configuration. By default, trailing whitespaces
2091 (including lines that consist solely of whitespaces) and a space
2092 character that is immediately followed by a tab character inside
2093 the initial indent of the line are considered whitespace errors.
2094 Exits with non-zero status if problems are found. Not compatible
2095 with --exit-code.
2096 --ws-error-highlight=<kind>
2098 Highlight whitespace errors in the context, old or new lines of the
2099 diff. Multiple values are separated by comma, none resets previous
2100 values, default reset the list to new and all is a shorthand for
2101 old,new,context. When this option is not given, and the
2102 configuration variable diff.wsErrorHighlight is not set, only
2103 whitespace errors in new lines are highlighted. The whitespace
2104 errors are colored with color.diff.whitespace.
2105 --full-index
2107 Instead of the first handful of characters, show the full pre- and
2108 post-image blob object names on the "index" line when generating
2109 patch format output.
2110 --binary
2112 In addition to --full-index, output a binary diff that can be
2113 applied with git-apply. Implies --patch.
2114 --abbrev[=<n>]
2116 Instead of showing the full 40-byte hexadecimal object name in
2117 diff-raw format output and diff-tree header lines, show the
2118 shortest prefix that is at least <n> hexdigits long that uniquely
2119 refers the object. In diff-patch output format, --full-index takes
2120 higher precedence, i.e. if --full-index is specified, full blob
2121 names will be shown regardless of --abbrev. Non default number of
2122 digits can be specified with --abbrev=<n>.
2123 -B[<n>][/<m>], --break-rewrites[=[<n>][/<m>]]
2125 Break complete rewrite changes into pairs of delete and create.
2126 This serves two purposes:
2127 It affects the way a change that amounts to a total rewrite of a
2129 file not as a series of deletion and insertion mixed together with
2130 a very few lines that happen to match textually as the context, but
2131 as a single deletion of everything old followed by a single
2132 insertion of everything new, and the number m controls this aspect
2133 of the -B option (defaults to 60%). -B/70% specifies that less
2134 than 30% of the original should remain in the result for Git to
2135 consider it a total rewrite (i.e. otherwise the resulting patch
2136 will be a series of deletion and insertion mixed together with
2137 context lines).
2138 When used with -M, a totally-rewritten file is also considered as
2140 the source of a rename (usually -M only considers a file that
2141 disappeared as the source of a rename), and the number n controls
2142 this aspect of the -B option (defaults to 50%). -B20% specifies
2143 that a change with addition and deletion compared to 20% or more of
2144 the file’s size are eligible for being picked up as a possible
2145 source of a rename to another file.
2146 -M[<n>], --find-renames[=<n>]
2148 If generating diffs, detect and report renames for each commit. For
2149 following files across renames while traversing history, see
2150 --follow. If n is specified, it is a threshold on the similarity
2151 index (i.e. amount of addition/deletions compared to the file’s
2152 size). For example, -M90% means Git should consider a delete/add
2153 pair to be a rename if more than 90% of the file hasn’t changed.
2154 Without a % sign, the number is to be read as a fraction, with a
2155 decimal point before it. I.e., -M5 becomes 0.5, and is thus the
2156 same as -M50%. Similarly, -M05 is the same as -M5%. To limit
2157 detection to exact renames, use -M100%. The default similarity
2158 index is 50%.
2159 -C[<n>], --find-copies[=<n>]
2161 Detect copies as well as renames. See also --find-copies-harder. If
2162 n is specified, it has the same meaning as for -M<n>.
2163 --find-copies-harder
2165 For performance reasons, by default, -C option finds copies only if
2166 the original file of the copy was modified in the same changeset.
2167 This flag makes the command inspect unmodified files as candidates
2168 for the source of copy. This is a very expensive operation for
2169 large projects, so use it with caution. Giving more than one -C
2170 option has the same effect.
2171 -D, --irreversible-delete
2173 Omit the preimage for deletes, i.e. print only the header but not
2174 the diff between the preimage and /dev/null. The resulting patch is
2175 not meant to be applied with patch or git apply; this is solely for
2176 people who want to just concentrate on reviewing the text after the
2177 change. In addition, the output obviously lacks enough information
2178 to apply such a patch in reverse, even manually, hence the name of
2179 the option.
2180 When used together with -B, omit also the preimage in the deletion
2182 part of a delete/create pair.
2183 -l<num>
2185 The -M and -C options involve some preliminary steps that can
2186 detect subsets of renames/copies cheaply, followed by an exhaustive
2187 fallback portion that compares all remaining unpaired destinations
2188 to all relevant sources. (For renames, only remaining unpaired
2189 sources are relevant; for copies, all original sources are
2190 relevant.) For N sources and destinations, this exhaustive check is
2191 O(N^2). This option prevents the exhaustive portion of rename/copy
2192 detection from running if the number of source/destination files
2193 involved exceeds the specified number. Defaults to
2194 diff.renameLimit. Note that a value of 0 is treated as unlimited.
2195 --diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
2197 Select only files that are Added (A), Copied (C), Deleted (D),
2198 Modified (M), Renamed (R), have their type (i.e. regular file,
2199 symlink, submodule, ...) changed (T), are Unmerged (U), are Unknown
2200 (X), or have had their pairing Broken (B). Any combination of the
2201 filter characters (including none) can be used. When *
2202 (All-or-none) is added to the combination, all paths are selected
2203 if there is any file that matches other criteria in the comparison;
2204 if there is no file that matches other criteria, nothing is
2205 selected.
2206 Also, these upper-case letters can be downcased to exclude. E.g.
2208 --diff-filter=ad excludes added and deleted paths.
2209 Note that not all diffs can feature all types. For instance, copied
2211 and renamed entries cannot appear if detection for those types is
2212 disabled.
2213 -S<string>
2215 Look for differences that change the number of occurrences of the
2216 specified string (i.e. addition/deletion) in a file. Intended for
2217 the scripter’s use.
2218 It is useful when you’re looking for an exact block of code (like a
2220 struct), and want to know the history of that block since it first
2221 came into being: use the feature iteratively to feed the
2222 interesting block in the preimage back into -S, and keep going
2223 until you get the very first version of the block.
2224 Binary files are searched as well.
2226 -G<regex>
2228 Look for differences whose patch text contains added/removed lines
2229 that match <regex>.
2230 To illustrate the difference between -S<regex> --pickaxe-regex and
2232 -G<regex>, consider a commit with the following diff in the same
2233 file:
2234 + return frotz(nitfol, two->ptr, 1, 0);
2236 ...
2237 - hit = frotz(nitfol, mf2.ptr, 1, 0);
2238 While git log -G"frotz\(nitfol" will show this commit, git log
2240 -S"frotz\(nitfol" --pickaxe-regex will not (because the number of
2241 occurrences of that string did not change).
2242 Unless --text is supplied patches of binary files without a
2244 textconv filter will be ignored.
2245 See the pickaxe entry in gitdiffcore(7) for more information.
2247 --find-object=<object-id>
2249 Look for differences that change the number of occurrences of the
2250 specified object. Similar to -S, just the argument is different in
2251 that it doesn’t search for a specific string but for a specific
2252 object id.
2253 The object can be a blob or a submodule commit. It implies the -t
2255 option in git-log to also find trees.
2256 --pickaxe-all
2258 When -S or -G finds a change, show all the changes in that
2259 changeset, not just the files that contain the change in <string>.
2260 --pickaxe-regex
2262 Treat the <string> given to -S as an extended POSIX regular
2263 expression to match.
2264 -O<orderfile>
2266 Control the order in which files appear in the output. This
2267 overrides the diff.orderFile configuration variable (see git-
2268 config(1)). To cancel diff.orderFile, use -O/dev/null.
2269 The output order is determined by the order of glob patterns in
2271 <orderfile>. All files with pathnames that match the first pattern
2272 are output first, all files with pathnames that match the second
2273 pattern (but not the first) are output next, and so on. All files
2274 with pathnames that do not match any pattern are output last, as if
2275 there was an implicit match-all pattern at the end of the file. If
2276 multiple pathnames have the same rank (they match the same pattern
2277 but no earlier patterns), their output order relative to each other
2278 is the normal order.
2279 <orderfile> is parsed as follows:
2281 • Blank lines are ignored, so they can be used as separators for
2283 readability.
2284 • Lines starting with a hash ("#") are ignored, so they can be
2286 used for comments. Add a backslash ("\") to the beginning of
2287 the pattern if it starts with a hash.
2288 • Each other line contains a single pattern.
2290 Patterns have the same syntax and semantics as patterns used for
2292 fnmatch(3) without the FNM_PATHNAME flag, except a pathname also
2293 matches a pattern if removing any number of the final pathname
2294 components matches the pattern. For example, the pattern "foo*bar"
2295 matches "fooasdfbar" and "foo/bar/baz/asdf" but not "foobarx".
2296 --skip-to=<file>, --rotate-to=<file>
2298 Discard the files before the named <file> from the output (i.e.
2299 skip to), or move them to the end of the output (i.e. rotate to).
2300 These options were invented primarily for the use of the git
2301 difftool command, and may not be very useful otherwise.
2302 -R
2304 Swap two inputs; that is, show differences from index or on-disk
2305 file to tree contents.
2306 --relative[=<path>], --no-relative
2308 When run from a subdirectory of the project, it can be told to
2309 exclude changes outside the directory and show pathnames relative
2310 to it with this option. When you are not in a subdirectory (e.g. in
2311 a bare repository), you can name which subdirectory to make the
2312 output relative to by giving a <path> as an argument.
2313 --no-relative can be used to countermand both diff.relative config
2314 option and previous --relative.
2315 -a, --text
2317 Treat all files as text.
2318 --ignore-cr-at-eol
2320 Ignore carriage-return at the end of line when doing a comparison.
2321 --ignore-space-at-eol
2323 Ignore changes in whitespace at EOL.
2324 -b, --ignore-space-change
2326 Ignore changes in amount of whitespace. This ignores whitespace at
2327 line end, and considers all other sequences of one or more
2328 whitespace characters to be equivalent.
2329 -w, --ignore-all-space
2331 Ignore whitespace when comparing lines. This ignores differences
2332 even if one line has whitespace where the other line has none.
2333 --ignore-blank-lines
2335 Ignore changes whose lines are all blank.
2336 -I<regex>, --ignore-matching-lines=<regex>
2338 Ignore changes whose all lines match <regex>. This option may be
2339 specified more than once.
2340 --inter-hunk-context=<lines>
2342 Show the context between diff hunks, up to the specified number of
2343 lines, thereby fusing hunks that are close to each other. Defaults
2344 to diff.interHunkContext or 0 if the config option is unset.
2345 -W, --function-context
2347 Show whole function as context lines for each change. The function
2348 names are determined in the same way as git diff works out patch
2349 hunk headers (see Defining a custom hunk-header in
2350 gitattributes(5)).
2351 --ext-diff
2353 Allow an external diff helper to be executed. If you set an
2354 external diff driver with gitattributes(5), you need to use this
2355 option with git-log(1) and friends.
2356 --no-ext-diff
2358 Disallow external diff drivers.
2359 --textconv, --no-textconv
2361 Allow (or disallow) external text conversion filters to be run when
2362 comparing binary files. See gitattributes(5) for details. Because
2363 textconv filters are typically a one-way conversion, the resulting
2364 diff is suitable for human consumption, but cannot be applied. For
2365 this reason, textconv filters are enabled by default only for git-
2366 diff(1) and git-log(1), but not for git-format-patch(1) or diff
2367 plumbing commands.
2368 --ignore-submodules[=<when>]
2370 Ignore changes to submodules in the diff generation. <when> can be
2371 either "none", "untracked", "dirty" or "all", which is the default.
2372 Using "none" will consider the submodule modified when it either
2373 contains untracked or modified files or its HEAD differs from the
2374 commit recorded in the superproject and can be used to override any
2375 settings of the ignore option in git-config(1) or gitmodules(5).
2376 When "untracked" is used submodules are not considered dirty when
2377 they only contain untracked content (but they are still scanned for
2378 modified content). Using "dirty" ignores all changes to the work
2379 tree of submodules, only changes to the commits stored in the
2380 superproject are shown (this was the behavior until 1.7.0). Using
2381 "all" hides all changes to submodules.
2382 --src-prefix=<prefix>
2384 Show the given source prefix instead of "a/".
2385 --dst-prefix=<prefix>
2387 Show the given destination prefix instead of "b/".
2388 --no-prefix
2390 Do not show any source or destination prefix.
2391 --default-prefix
2393 Use the default source and destination prefixes ("a/" and "b/").
2394 This is usually the default already, but may be used to override
2395 config such as diff.noprefix.
2396 --line-prefix=<prefix>
2398 Prepend an additional prefix to every line of output.
2399 --ita-invisible-in-index
2401 By default entries added by "git add -N" appear as an existing
2402 empty file in "git diff" and a new file in "git diff --cached".
2403 This option makes the entry appear as a new file in "git diff" and
2404 non-existent in "git diff --cached". This option could be reverted
2405 with --ita-visible-in-index. Both options are experimental and
2406 could be removed in future.
2407 For more detailed explanation on these common options, see also
2409 gitdiffcore(7).
2410
2412 Running git-diff(1), git-log(1), git-show(1), git-diff-index(1), git-
2413 diff-tree(1), or git-diff-files(1) with the -p option produces patch
2414 text. You can customize the creation of patch text via the
2415 GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables (see
2416 git(1)), and the diff attribute (see gitattributes(5)).
2417 What the -p option produces is slightly different from the traditional
2419 diff format:
2420 1. It is preceded by a "git diff" header that looks like this:
2422 diff --git a/file1 b/file2
2424 The a/ and b/ filenames are the same unless rename/copy is
2426 involved. Especially, even for a creation or a deletion, /dev/null
2427 is not used in place of the a/ or b/ filenames.
2428 When a rename/copy is involved, file1 and file2 show the name of
2430 the source file of the rename/copy and the name of the file that
2431 the rename/copy produces, respectively.
2432 2. It is followed by one or more extended header lines:
2434 old mode <mode>
2436 new mode <mode>
2437 deleted file mode <mode>
2438 new file mode <mode>
2439 copy from <path>
2440 copy to <path>
2441 rename from <path>
2442 rename to <path>
2443 similarity index <number>
2444 dissimilarity index <number>
2445 index <hash>..<hash> <mode>
2446 File modes are printed as 6-digit octal numbers including the file
2448 type and file permission bits.
2449 Path names in extended headers do not include the a/ and b/
2451 prefixes.
2452 The similarity index is the percentage of unchanged lines, and the
2454 dissimilarity index is the percentage of changed lines. It is a
2455 rounded down integer, followed by a percent sign. The similarity
2456 index value of 100% is thus reserved for two equal files, while
2457 100% dissimilarity means that no line from the old file made it
2458 into the new one.
2459 The index line includes the blob object names before and after the
2461 change. The <mode> is included if the file mode does not change;
2462 otherwise, separate lines indicate the old and the new mode.
2463 3. Pathnames with "unusual" characters are quoted as explained for the
2465 configuration variable core.quotePath (see git-config(1)).
2466 4. All the file1 files in the output refer to files before the commit,
2468 and all the file2 files refer to files after the commit. It is
2469 incorrect to apply each change to each file sequentially. For
2470 example, this patch will swap a and b:
2471 diff --git a/a b/b
2473 rename from a
2474 rename to b
2475 diff --git a/b b/a
2476 rename from b
2477 rename to a
2478 5. Hunk headers mention the name of the function to which the hunk
2480 applies. See "Defining a custom hunk-header" in gitattributes(5)
2481 for details of how to tailor this to specific languages.
2482
2484 Any diff-generating command can take the -c or --cc option to produce a
2485 combined diff when showing a merge. This is the default format when
2486 showing merges with git-diff(1) or git-show(1). Note also that you can
2487 give suitable --diff-merges option to any of these commands to force
2488 generation of diffs in a specific format.
2489 A "combined diff" format looks like this:
2491 diff --combined describe.c
2493 index fabadb8,cc95eb0..4866510
2494 --- a/describe.c
2495 +++ b/describe.c
2496 @@@ -98,20 -98,12 +98,20 @@@
2497 return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
2498 }
2499 - static void describe(char *arg)
2501 -static void describe(struct commit *cmit, int last_one)
2502 ++static void describe(char *arg, int last_one)
2503 {
2504 + unsigned char sha1[20];
2505 + struct commit *cmit;
2506 struct commit_list *list;
2507 static int initialized = 0;
2508 struct commit_name *n;
2509 + if (get_sha1(arg, sha1) < 0)
2511 + usage(describe_usage);
2512 + cmit = lookup_commit_reference(sha1);
2513 + if (!cmit)
2514 + usage(describe_usage);
2515 +
2516 if (!initialized) {
2517 initialized = 1;
2518 for_each_ref(get_name);
2519 1. It is preceded by a "git diff" header, that looks like this (when
2521 the -c option is used):
2522 diff --combined file
2524 or like this (when the --cc option is used):
2526 diff --cc file
2528 2. It is followed by one or more extended header lines (this example
2530 shows a merge with two parents):
2531 index <hash>,<hash>..<hash>
2533 mode <mode>,<mode>..<mode>
2534 new file mode <mode>
2535 deleted file mode <mode>,<mode>
2536 The mode <mode>,<mode>..<mode> line appears only if at least one of
2538 the <mode> is different from the rest. Extended headers with
2539 information about detected content movement (renames and copying
2540 detection) are designed to work with the diff of two <tree-ish> and
2541 are not used by combined diff format.
2542 3. It is followed by a two-line from-file/to-file header:
2544 --- a/file
2546 +++ b/file
2547 Similar to the two-line header for the traditional unified diff
2549 format, /dev/null is used to signal created or deleted files.
2550 However, if the --combined-all-paths option is provided, instead of
2552 a two-line from-file/to-file, you get an N+1 line from-file/to-file
2553 header, where N is the number of parents in the merge commit:
2554 --- a/file
2556 --- a/file
2557 --- a/file
2558 +++ b/file
2559 This extended format can be useful if rename or copy detection is
2561 active, to allow you to see the original name of the file in
2562 different parents.
2563 4. Chunk header format is modified to prevent people from accidentally
2565 feeding it to patch -p1. Combined diff format was created for
2566 review of merge commit changes, and was not meant to be applied.
2567 The change is similar to the change in the extended index header:
2568 @@@ <from-file-range> <from-file-range> <to-file-range> @@@
2570 There are (number of parents + 1) @ characters in the chunk header
2572 for combined diff format.
2573 Unlike the traditional unified diff format, which shows two files A and
2575 B with a single column that has - (minus — appears in A but removed in
2576 B), + (plus — missing in A but added to B), or " " (space — unchanged)
2577 prefix, this format compares two or more files file1, file2,... with
2578 one file X, and shows how X differs from each of fileN. One column for
2579 each of fileN is prepended to the output line to note how X’s line is
2580 different from it.
2581 A - character in the column N means that the line appears in fileN but
2583 it does not appear in the result. A + character in the column N means
2584 that the line appears in the result, and fileN does not have that line
2585 (in other words, the line was added, from the point of view of that
2586 parent).
2587 In the above example output, the function signature was changed from
2589 both files (hence two - removals from both file1 and file2, plus ++ to
2590 mean one line that was added does not appear in either file1 or file2).
2591 Also, eight other lines are the same from file1 but do not appear in
2592 file2 (hence prefixed with +).
2593 When shown by git diff-tree -c, it compares the parents of a merge
2595 commit with the merge result (i.e. file1..fileN are the parents). When
2596 shown by git diff-files -c, it compares the two unresolved merge
2597 parents with the working tree file (i.e. file1 is stage 2 aka "our
2598 version", file2 is stage 3 aka "their version").
2599
2601 git log --no-merges
2602 Show the whole commit history, but skip any merges
2603 git log v2.6.12.. include/scsi drivers/scsi
2605 Show all commits since version v2.6.12 that changed any file in the
2606 include/scsi or drivers/scsi subdirectories
2607 git log --since="2 weeks ago" -- gitk
2609 Show the changes during the last two weeks to the file gitk. The --
2610 is necessary to avoid confusion with the branch named gitk
2611 git log --name-status release..test
2613 Show the commits that are in the "test" branch but not yet in the
2614 "release" branch, along with the list of paths each commit
2615 modifies.
2616 git log --follow builtin/rev-list.c
2618 Shows the commits that changed builtin/rev-list.c, including those
2619 commits that occurred before the file was given its present name.
2620 git log --branches --not --remotes=origin
2622 Shows all commits that are in any of local branches but not in any
2623 of remote-tracking branches for origin (what you have that origin
2624 doesn’t).
2625 git log master --not --remotes=*/master
2627 Shows all commits that are in local master but not in any remote
2628 repository master branches.
2629 git log -p -m --first-parent
2631 Shows the history including change diffs, but only from the “main
2632 branch” perspective, skipping commits that come from merged
2633 branches, and showing full diffs of changes introduced by the
2634 merges. This makes sense only when following a strict policy of
2635 merging all topic branches when staying on a single integration
2636 branch.
2637 git log -L '/int main/',/^}/:main.c
2639 Shows how the function main() in the file main.c evolved over time.
2640 git log -3
2642 Limits the number of commits to show to 3.
2643
2645 Git is to some extent character encoding agnostic.
2646 • The contents of the blob objects are uninterpreted sequences of
2648 bytes. There is no encoding translation at the core level.
2649 • Path names are encoded in UTF-8 normalization form C. This applies
2651 to tree objects, the index file, ref names, as well as path names
2652 in command line arguments, environment variables and config files
2653 (.git/config (see git-config(1)), gitignore(5), gitattributes(5)
2654 and gitmodules(5)).
2655 Note that Git at the core level treats path names simply as
2657 sequences of non-NUL bytes, there are no path name encoding
2658 conversions (except on Mac and Windows). Therefore, using non-ASCII
2659 path names will mostly work even on platforms and file systems that
2660 use legacy extended ASCII encodings. However, repositories created
2661 on such systems will not work properly on UTF-8-based systems (e.g.
2662 Linux, Mac, Windows) and vice versa. Additionally, many Git-based
2663 tools simply assume path names to be UTF-8 and will fail to display
2664 other encodings correctly.
2665 • Commit log messages are typically encoded in UTF-8, but other
2667 extended ASCII encodings are also supported. This includes
2668 ISO-8859-x, CP125x and many others, but not UTF-16/32, EBCDIC and
2669 CJK multi-byte encodings (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).
2670 Although we encourage that the commit log messages are encoded in
2672 UTF-8, both the core and Git Porcelain are designed not to force UTF-8
2673 on projects. If all participants of a particular project find it more
2674 convenient to use legacy encodings, Git does not forbid it. However,
2675 there are a few things to keep in mind.
2676 1. git commit and git commit-tree issue a warning if the commit log
2678 message given to it does not look like a valid UTF-8 string, unless
2679 you explicitly say your project uses a legacy encoding. The way to
2680 say this is to have i18n.commitEncoding in .git/config file, like
2681 this:
2682 [i18n]
2684 commitEncoding = ISO-8859-1
2685 Commit objects created with the above setting record the value of
2687 i18n.commitEncoding in their encoding header. This is to help other
2688 people who look at them later. Lack of this header implies that the
2689 commit log message is encoded in UTF-8.
2690 2. git log, git show, git blame and friends look at the encoding
2692 header of a commit object, and try to re-code the log message into
2693 UTF-8 unless otherwise specified. You can specify the desired
2694 output encoding with i18n.logOutputEncoding in .git/config file,
2695 like this:
2696 [i18n]
2698 logOutputEncoding = ISO-8859-1
2699 If you do not have this configuration variable, the value of
2701 i18n.commitEncoding is used instead.
2702 Note that we deliberately chose not to re-code the commit log message
2704 when a commit is made to force UTF-8 at the commit object level,
2705 because re-coding to UTF-8 is not necessarily a reversible operation.
2706
2708 See git-config(1) for core variables and git-diff(1) for settings
2709 related to diff generation.
2710 format.pretty
2712 Default for the --format option. (See Pretty Formats above.)
2713 Defaults to medium.
2714 i18n.logOutputEncoding
2716 Encoding to use when displaying logs. (See Discussion above.)
2717 Defaults to the value of i18n.commitEncoding if set, and UTF-8
2718 otherwise.
2719 Everything above this line in this section isn’t included from the git-
2721 config(1) documentation. The content that follows is the same as what’s
2722 found there:
2723 log.abbrevCommit
2725 If true, makes git-log(1), git-show(1), and git-whatchanged(1)
2726 assume --abbrev-commit. You may override this option with
2727 --no-abbrev-commit.
2728 log.date
2730 Set the default date-time mode for the log command. Setting a value
2731 for log.date is similar to using git log's --date option. See git-
2732 log(1) for details.
2733 If the format is set to "auto:foo" and the pager is in use, format
2735 "foo" will be used for the date format. Otherwise, "default" will
2736 be used.
2737 log.decorate
2739 Print out the ref names of any commits that are shown by the log
2740 command. If short is specified, the ref name prefixes refs/heads/,
2741 refs/tags/ and refs/remotes/ will not be printed. If full is
2742 specified, the full ref name (including prefix) will be printed. If
2743 auto is specified, then if the output is going to a terminal, the
2744 ref names are shown as if short were given, otherwise no ref names
2745 are shown. This is the same as the --decorate option of the git
2746 log.
2747 log.initialDecorationSet
2749 By default, git log only shows decorations for certain known ref
2750 namespaces. If all is specified, then show all refs as decorations.
2751 log.excludeDecoration
2753 Exclude the specified patterns from the log decorations. This is
2754 similar to the --decorate-refs-exclude command-line option, but the
2755 config option can be overridden by the --decorate-refs option.
2756 log.diffMerges
2758 Set diff format to be used when --diff-merges=on is specified, see
2759 --diff-merges in git-log(1) for details. Defaults to separate.
2760 log.follow
2762 If true, git log will act as if the --follow option was used when a
2763 single <path> is given. This has the same limitations as --follow,
2764 i.e. it cannot be used to follow multiple files and does not work
2765 well on non-linear history.
2766 log.graphColors
2768 A list of colors, separated by commas, that can be used to draw
2769 history lines in git log --graph.
2770 log.showRoot
2772 If true, the initial commit will be shown as a big creation event.
2773 This is equivalent to a diff against an empty tree. Tools like git-
2774 log(1) or git-whatchanged(1), which normally hide the root commit
2775 will now show it. True by default.
2776 log.showSignature
2778 If true, makes git-log(1), git-show(1), and git-whatchanged(1)
2779 assume --show-signature.
2780 log.mailmap
2782 If true, makes git-log(1), git-show(1), and git-whatchanged(1)
2783 assume --use-mailmap, otherwise assume --no-use-mailmap. True by
2784 default.
2785 notes.mergeStrategy
2787 Which merge strategy to choose by default when resolving notes
2788 conflicts. Must be one of manual, ours, theirs, union, or
2789 cat_sort_uniq. Defaults to manual. See the "NOTES MERGE STRATEGIES"
2790 section of git-notes(1) for more information on each strategy.
2791 This setting can be overridden by passing the --strategy option to
2793 git-notes(1).
2794 notes.<name>.mergeStrategy
2796 Which merge strategy to choose when doing a notes merge into
2797 refs/notes/<name>. This overrides the more general
2798 "notes.mergeStrategy". See the "NOTES MERGE STRATEGIES" section in
2799 git-notes(1) for more information on the available strategies.
2800 notes.displayRef
2802 Which ref (or refs, if a glob or specified more than once), in
2803 addition to the default set by core.notesRef or GIT_NOTES_REF, to
2804 read notes from when showing commit messages with the git log
2805 family of commands.
2806 This setting can be overridden with the GIT_NOTES_DISPLAY_REF
2808 environment variable, which must be a colon separated list of refs
2809 or globs.
2810 A warning will be issued for refs that do not exist, but a glob
2812 that does not match any refs is silently ignored.
2813 This setting can be disabled by the --no-notes option to the git
2815 log family of commands, or by the --notes=<ref> option accepted by
2816 those commands.
2817 The effective value of "core.notesRef" (possibly overridden by
2819 GIT_NOTES_REF) is also implicitly added to the list of refs to be
2820 displayed.
2821 notes.rewrite.<command>
2823 When rewriting commits with <command> (currently amend or rebase),
2824 if this variable is false, git will not copy notes from the
2825 original to the rewritten commit. Defaults to true. See also
2826 "notes.rewriteRef" below.
2827 This setting can be overridden with the GIT_NOTES_REWRITE_REF
2829 environment variable, which must be a colon separated list of refs
2830 or globs.
2831 notes.rewriteMode
2833 When copying notes during a rewrite (see the
2834 "notes.rewrite.<command>" option), determines what to do if the
2835 target commit already has a note. Must be one of overwrite,
2836 concatenate, cat_sort_uniq, or ignore. Defaults to concatenate.
2837 This setting can be overridden with the GIT_NOTES_REWRITE_MODE
2839 environment variable.
2840 notes.rewriteRef
2842 When copying notes during a rewrite, specifies the (fully
2843 qualified) ref whose notes should be copied. May be a glob, in
2844 which case notes in all matching refs will be copied. You may also
2845 specify this configuration several times.
2846 Does not have a default value; you must configure this variable to
2848 enable note rewriting. Set it to refs/notes/commits to enable
2849 rewriting for the default commit notes.
2850 Can be overridden with the GIT_NOTES_REWRITE_REF environment
2852 variable. See notes.rewrite.<command> above for a further
2853 description of its format.
2854
2856 Part of the git(1) suite
2857Git 2.43.0 11/20/2023 GIT-LOG(1)