1GIT-REV-LIST(1)                   Git Manual                   GIT-REV-LIST(1)
2
3
4

NAME

6       git-rev-list - Lists commit objects in reverse chronological order
7

SYNOPSIS

9       git rev-list [<options>] <commit>... [[--] <path>...]
10

DESCRIPTION

12       List commits that are reachable by following the parent links from the
13       given commit(s), but exclude commits that are reachable from the one(s)
14       given with a ^ in front of them. The output is given in reverse
15       chronological order by default.
16
17       You can think of this as a set operation. Commits reachable from any of
18       the commits given on the command line form a set, and then commits
19       reachable from any of the ones given with ^ in front are subtracted
20       from that set. The remaining commits are what comes out in the
21       command’s output. Various other options and paths parameters can be
22       used to further limit the result.
23
24       Thus, the following command:
25
26           $ git rev-list foo bar ^baz
27
28       means "list all the commits which are reachable from foo or bar, but
29       not from baz".
30
31       A special notation "<commit1>..<commit2>" can be used as a short-hand
32       for "^<commit1> <commit2>". For example, either of the following may be
33       used interchangeably:
34
35           $ git rev-list origin..HEAD
36           $ git rev-list HEAD ^origin
37
38       Another special notation is "<commit1>...<commit2>" which is useful for
39       merges. The resulting set of commits is the symmetric difference
40       between the two operands. The following two commands are equivalent:
41
42           $ git rev-list A B --not $(git merge-base --all A B)
43           $ git rev-list A...B
44
45       rev-list is a very essential Git command, since it provides the ability
46       to build and traverse commit ancestry graphs. For this reason, it has a
47       lot of different options that enables it to be used by commands as
48       different as git bisect and git repack.
49

OPTIONS

51   Commit Limiting
52       Besides specifying a range of commits that should be listed using the
53       special notations explained in the description, additional commit
54       limiting may be applied.
55
56       Using more options generally further limits the output (e.g.
57       --since=<date1> limits to commits newer than <date1>, and using it with
58       --grep=<pattern> further limits to commits whose log message has a line
59       that matches <pattern>), unless otherwise noted.
60
61       Note that these are applied before commit ordering and formatting
62       options, such as --reverse.
63
64       -<number>, -n <number>, --max-count=<number>
65           Limit the number of commits to output.
66
67       --skip=<number>
68           Skip number commits before starting to show the commit output.
69
70       --since=<date>, --after=<date>
71           Show commits more recent than a specific date.
72
73       --until=<date>, --before=<date>
74           Show commits older than a specific date.
75
76       --max-age=<timestamp>, --min-age=<timestamp>
77           Limit the commits output to specified time range.
78
79       --author=<pattern>, --committer=<pattern>
80           Limit the commits output to ones with author/committer header lines
81           that match the specified pattern (regular expression). With more
82           than one --author=<pattern>, commits whose author matches any of
83           the given patterns are chosen (similarly for multiple
84           --committer=<pattern>).
85
86       --grep-reflog=<pattern>
87           Limit the commits output to ones with reflog entries that match the
88           specified pattern (regular expression). With more than one
89           --grep-reflog, commits whose reflog message matches any of the
90           given patterns are chosen. It is an error to use this option unless
91           --walk-reflogs is in use.
92
93       --grep=<pattern>
94           Limit the commits output to ones with log message that matches the
95           specified pattern (regular expression). With more than one
96           --grep=<pattern>, commits whose message matches any of the given
97           patterns are chosen (but see --all-match).
98
99       --all-match
100           Limit the commits output to ones that match all given --grep,
101           instead of ones that match at least one.
102
103       --invert-grep
104           Limit the commits output to ones with log message that do not match
105           the pattern specified with --grep=<pattern>.
106
107       -i, --regexp-ignore-case
108           Match the regular expression limiting patterns without regard to
109           letter case.
110
111       --basic-regexp
112           Consider the limiting patterns to be basic regular expressions;
113           this is the default.
114
115       -E, --extended-regexp
116           Consider the limiting patterns to be extended regular expressions
117           instead of the default basic regular expressions.
118
119       -F, --fixed-strings
120           Consider the limiting patterns to be fixed strings (don’t interpret
121           pattern as a regular expression).
122
123       -P, --perl-regexp
124           Consider the limiting patterns to be Perl-compatible regular
125           expressions.
126
127           Support for these types of regular expressions is an optional
128           compile-time dependency. If Git wasn’t compiled with support for
129           them providing this option will cause it to die.
130
131       --remove-empty
132           Stop when a given path disappears from the tree.
133
134       --merges
135           Print only merge commits. This is exactly the same as
136           --min-parents=2.
137
138       --no-merges
139           Do not print commits with more than one parent. This is exactly the
140           same as --max-parents=1.
141
142       --min-parents=<number>, --max-parents=<number>, --no-min-parents,
143       --no-max-parents
144           Show only commits which have at least (or at most) that many parent
145           commits. In particular, --max-parents=1 is the same as --no-merges,
146           --min-parents=2 is the same as --merges.  --max-parents=0 gives all
147           root commits and --min-parents=3 all octopus merges.
148
149           --no-min-parents and --no-max-parents reset these limits (to no
150           limit) again. Equivalent forms are --min-parents=0 (any commit has
151           0 or more parents) and --max-parents=-1 (negative numbers denote no
152           upper limit).
153
154       --first-parent
155           Follow only the first parent commit upon seeing a merge commit.
156           This option can give a better overview when viewing the evolution
157           of a particular topic branch, because merges into a topic branch
158           tend to be only about adjusting to updated upstream from time to
159           time, and this option allows you to ignore the individual commits
160           brought in to your history by such a merge.
161
162       --not
163           Reverses the meaning of the ^ prefix (or lack thereof) for all
164           following revision specifiers, up to the next --not.
165
166       --all
167           Pretend as if all the refs in refs/, along with HEAD, are listed on
168           the command line as <commit>.
169
170       --branches[=<pattern>]
171           Pretend as if all the refs in refs/heads are listed on the command
172           line as <commit>. If <pattern> is given, limit branches to ones
173           matching given shell glob. If pattern lacks ?, *, or [, /* at the
174           end is implied.
175
176       --tags[=<pattern>]
177           Pretend as if all the refs in refs/tags are listed on the command
178           line as <commit>. If <pattern> is given, limit tags to ones
179           matching given shell glob. If pattern lacks ?, *, or [, /* at the
180           end is implied.
181
182       --remotes[=<pattern>]
183           Pretend as if all the refs in refs/remotes are listed on the
184           command line as <commit>. If <pattern> is given, limit
185           remote-tracking branches to ones matching given shell glob. If
186           pattern lacks ?, *, or [, /* at the end is implied.
187
188       --glob=<glob-pattern>
189           Pretend as if all the refs matching shell glob <glob-pattern> are
190           listed on the command line as <commit>. Leading refs/, is
191           automatically prepended if missing. If pattern lacks ?, *, or [, /*
192           at the end is implied.
193
194       --exclude=<glob-pattern>
195           Do not include refs matching <glob-pattern> that the next --all,
196           --branches, --tags, --remotes, or --glob would otherwise consider.
197           Repetitions of this option accumulate exclusion patterns up to the
198           next --all, --branches, --tags, --remotes, or --glob option (other
199           options or arguments do not clear accumulated patterns).
200
201           The patterns given should not begin with refs/heads, refs/tags, or
202           refs/remotes when applied to --branches, --tags, or --remotes,
203           respectively, and they must begin with refs/ when applied to --glob
204           or --all. If a trailing /* is intended, it must be given
205           explicitly.
206
207       --reflog
208           Pretend as if all objects mentioned by reflogs are listed on the
209           command line as <commit>.
210
211       --alternate-refs
212           Pretend as if all objects mentioned as ref tips of alternate
213           repositories were listed on the command line. An alternate
214           repository is any repository whose object directory is specified in
215           objects/info/alternates. The set of included objects may be
216           modified by core.alternateRefsCommand, etc. See git-config(1).
217
218       --single-worktree
219           By default, all working trees will be examined by the following
220           options when there are more than one (see git-worktree(1)): --all,
221           --reflog and --indexed-objects. This option forces them to examine
222           the current working tree only.
223
224       --ignore-missing
225           Upon seeing an invalid object name in the input, pretend as if the
226           bad input was not given.
227
228       --stdin
229           In addition to the <commit> listed on the command line, read them
230           from the standard input. If a -- separator is seen, stop reading
231           commits and start reading paths to limit the result.
232
233       --quiet
234           Don’t print anything to standard output. This form is primarily
235           meant to allow the caller to test the exit status to see if a range
236           of objects is fully connected (or not). It is faster than
237           redirecting stdout to /dev/null as the output does not have to be
238           formatted.
239
240       --cherry-mark
241           Like --cherry-pick (see below) but mark equivalent commits with =
242           rather than omitting them, and inequivalent ones with +.
243
244       --cherry-pick
245           Omit any commit that introduces the same change as another commit
246           on the “other side” when the set of commits are limited with
247           symmetric difference.
248
249           For example, if you have two branches, A and B, a usual way to list
250           all commits on only one side of them is with --left-right (see the
251           example below in the description of the --left-right option).
252           However, it shows the commits that were cherry-picked from the
253           other branch (for example, “3rd on b” may be cherry-picked from
254           branch A). With this option, such pairs of commits are excluded
255           from the output.
256
257       --left-only, --right-only
258           List only commits on the respective side of a symmetric difference,
259           i.e. only those which would be marked < resp.  > by --left-right.
260
261           For example, --cherry-pick --right-only A...B omits those commits
262           from B which are in A or are patch-equivalent to a commit in A. In
263           other words, this lists the + commits from git cherry A B. More
264           precisely, --cherry-pick --right-only --no-merges gives the exact
265           list.
266
267       --cherry
268           A synonym for --right-only --cherry-mark --no-merges; useful to
269           limit the output to the commits on our side and mark those that
270           have been applied to the other side of a forked history with git
271           log --cherry upstream...mybranch, similar to git cherry upstream
272           mybranch.
273
274       -g, --walk-reflogs
275           Instead of walking the commit ancestry chain, walk reflog entries
276           from the most recent one to older ones. When this option is used
277           you cannot specify commits to exclude (that is, ^commit,
278           commit1..commit2, and commit1...commit2 notations cannot be used).
279
280           With --pretty format other than oneline and reference (for obvious
281           reasons), this causes the output to have two extra lines of
282           information taken from the reflog. The reflog designator in the
283           output may be shown as ref@{Nth} (where Nth is the
284           reverse-chronological index in the reflog) or as ref@{timestamp}
285           (with the timestamp for that entry), depending on a few rules:
286
287            1. If the starting point is specified as ref@{Nth}, show the index
288               format.
289
290            2. If the starting point was specified as ref@{now}, show the
291               timestamp format.
292
293            3. If neither was used, but --date was given on the command line,
294               show the timestamp in the format requested by --date.
295
296            4. Otherwise, show the index format.
297
298           Under --pretty=oneline, the commit message is prefixed with this
299           information on the same line. This option cannot be combined with
300           --reverse. See also git-reflog(1).
301
302           Under --pretty=reference, this information will not be shown at
303           all.
304
305       --merge
306           After a failed merge, show refs that touch files having a conflict
307           and don’t exist on all heads to merge.
308
309       --boundary
310           Output excluded boundary commits. Boundary commits are prefixed
311           with -.
312
313       --use-bitmap-index
314           Try to speed up the traversal using the pack bitmap index (if one
315           is available). Note that when traversing with --objects, trees and
316           blobs will not have their associated path printed.
317
318       --progress=<header>
319           Show progress reports on stderr as objects are considered. The
320           <header> text will be printed with each progress update.
321
322   History Simplification
323       Sometimes you are only interested in parts of the history, for example
324       the commits modifying a particular <path>. But there are two parts of
325       History Simplification, one part is selecting the commits and the other
326       is how to do it, as there are various strategies to simplify the
327       history.
328
329       The following options select the commits to be shown:
330
331       <paths>
332           Commits modifying the given <paths> are selected.
333
334       --simplify-by-decoration
335           Commits that are referred by some branch or tag are selected.
336
337       Note that extra commits can be shown to give a meaningful history.
338
339       The following options affect the way the simplification is performed:
340
341       Default mode
342           Simplifies the history to the simplest history explaining the final
343           state of the tree. Simplest because it prunes some side branches if
344           the end result is the same (i.e. merging branches with the same
345           content)
346
347       --show-pulls
348           Include all commits from the default mode, but also any merge
349           commits that are not TREESAME to the first parent but are TREESAME
350           to a later parent. This mode is helpful for showing the merge
351           commits that "first introduced" a change to a branch.
352
353       --full-history
354           Same as the default mode, but does not prune some history.
355
356       --dense
357           Only the selected commits are shown, plus some to have a meaningful
358           history.
359
360       --sparse
361           All commits in the simplified history are shown.
362
363       --simplify-merges
364           Additional option to --full-history to remove some needless merges
365           from the resulting history, as there are no selected commits
366           contributing to this merge.
367
368       --ancestry-path
369           When given a range of commits to display (e.g.  commit1..commit2 or
370           commit2 ^commit1), only display commits that exist directly on the
371           ancestry chain between the commit1 and commit2, i.e. commits that
372           are both descendants of commit1, and ancestors of commit2.
373
374       A more detailed explanation follows.
375
376       Suppose you specified foo as the <paths>. We shall call commits that
377       modify foo !TREESAME, and the rest TREESAME. (In a diff filtered for
378       foo, they look different and equal, respectively.)
379
380       In the following, we will always refer to the same example history to
381       illustrate the differences between simplification settings. We assume
382       that you are filtering for a file foo in this commit graph:
383
384                     .-A---M---N---O---P---Q
385                    /     /   /   /   /   /
386                   I     B   C   D   E   Y
387                    \   /   /   /   /   /
388                     `-------------'   X
389
390       The horizontal line of history A---Q is taken to be the first parent of
391       each merge. The commits are:
392
393       ·   I is the initial commit, in which foo exists with contents “asdf”,
394           and a file quux exists with contents “quux”. Initial commits are
395           compared to an empty tree, so I is !TREESAME.
396
397       ·   In A, foo contains just “foo”.
398
399       ·   B contains the same change as A. Its merge M is trivial and hence
400           TREESAME to all parents.
401
402       ·   C does not change foo, but its merge N changes it to “foobar”, so
403           it is not TREESAME to any parent.
404
405       ·   D sets foo to “baz”. Its merge O combines the strings from N and D
406           to “foobarbaz”; i.e., it is not TREESAME to any parent.
407
408       ·   E changes quux to “xyzzy”, and its merge P combines the strings to
409           “quux xyzzy”.  P is TREESAME to O, but not to E.
410
411       ·   X is an independent root commit that added a new file side, and Y
412           modified it.  Y is TREESAME to X. Its merge Q added side to P, and
413           Q is TREESAME to P, but not to Y.
414
415       rev-list walks backwards through history, including or excluding
416       commits based on whether --full-history and/or parent rewriting (via
417       --parents or --children) are used. The following settings are
418       available.
419
420       Default mode
421           Commits are included if they are not TREESAME to any parent (though
422           this can be changed, see --sparse below). If the commit was a
423           merge, and it was TREESAME to one parent, follow only that parent.
424           (Even if there are several TREESAME parents, follow only one of
425           them.) Otherwise, follow all parents.
426
427           This results in:
428
429                         .-A---N---O
430                        /     /   /
431                       I---------D
432
433           Note how the rule to only follow the TREESAME parent, if one is
434           available, removed B from consideration entirely.  C was considered
435           via N, but is TREESAME. Root commits are compared to an empty tree,
436           so I is !TREESAME.
437
438           Parent/child relations are only visible with --parents, but that
439           does not affect the commits selected in default mode, so we have
440           shown the parent lines.
441
442       --full-history without parent rewriting
443           This mode differs from the default in one point: always follow all
444           parents of a merge, even if it is TREESAME to one of them. Even if
445           more than one side of the merge has commits that are included, this
446           does not imply that the merge itself is! In the example, we get
447
448                       I  A  B  N  D  O  P  Q
449
450           M was excluded because it is TREESAME to both parents.  E, C and B
451           were all walked, but only B was !TREESAME, so the others do not
452           appear.
453
454           Note that without parent rewriting, it is not really possible to
455           talk about the parent/child relationships between the commits, so
456           we show them disconnected.
457
458       --full-history with parent rewriting
459           Ordinary commits are only included if they are !TREESAME (though
460           this can be changed, see --sparse below).
461
462           Merges are always included. However, their parent list is
463           rewritten: Along each parent, prune away commits that are not
464           included themselves. This results in
465
466                         .-A---M---N---O---P---Q
467                        /     /   /   /   /
468                       I     B   /   D   /
469                        \   /   /   /   /
470                         `-------------'
471
472           Compare to --full-history without rewriting above. Note that E was
473           pruned away because it is TREESAME, but the parent list of P was
474           rewritten to contain E's parent I. The same happened for C and N,
475           and X, Y and Q.
476
477       In addition to the above settings, you can change whether TREESAME
478       affects inclusion:
479
480       --dense
481           Commits that are walked are included if they are not TREESAME to
482           any parent.
483
484       --sparse
485           All commits that are walked are included.
486
487           Note that without --full-history, this still simplifies merges: if
488           one of the parents is TREESAME, we follow only that one, so the
489           other sides of the merge are never walked.
490
491       --simplify-merges
492           First, build a history graph in the same way that --full-history
493           with parent rewriting does (see above).
494
495           Then simplify each commit C to its replacement C' in the final
496           history according to the following rules:
497
498           ·   Set C' to C.
499
500           ·   Replace each parent P of C' with its simplification P'. In the
501               process, drop parents that are ancestors of other parents or
502               that are root commits TREESAME to an empty tree, and remove
503               duplicates, but take care to never drop all parents that we are
504               TREESAME to.
505
506           ·   If after this parent rewriting, C' is a root or merge commit
507               (has zero or >1 parents), a boundary commit, or !TREESAME, it
508               remains. Otherwise, it is replaced with its only parent.
509
510           The effect of this is best shown by way of comparing to
511           --full-history with parent rewriting. The example turns into:
512
513                         .-A---M---N---O
514                        /     /       /
515                       I     B       D
516                        \   /       /
517                         `---------'
518
519           Note the major differences in N, P, and Q over --full-history:
520
521           ·   N's parent list had I removed, because it is an ancestor of the
522               other parent M. Still, N remained because it is !TREESAME.
523
524           ·   P's parent list similarly had I removed.  P was then removed
525               completely, because it had one parent and is TREESAME.
526
527           ·   Q's parent list had Y simplified to X.  X was then removed,
528               because it was a TREESAME root.  Q was then removed completely,
529               because it had one parent and is TREESAME.
530
531       There is another simplification mode available:
532
533       --ancestry-path
534           Limit the displayed commits to those directly on the ancestry chain
535           between the “from” and “to” commits in the given commit range. I.e.
536           only display commits that are ancestor of the “to” commit and
537           descendants of the “from” commit.
538
539           As an example use case, consider the following commit history:
540
541                           D---E-------F
542                          /     \       \
543                         B---C---G---H---I---J
544                        /                     \
545                       A-------K---------------L--M
546
547           A regular D..M computes the set of commits that are ancestors of M,
548           but excludes the ones that are ancestors of D. This is useful to
549           see what happened to the history leading to M since D, in the sense
550           that “what does M have that did not exist in D”. The result in this
551           example would be all the commits, except A and B (and D itself, of
552           course).
553
554           When we want to find out what commits in M are contaminated with
555           the bug introduced by D and need fixing, however, we might want to
556           view only the subset of D..M that are actually descendants of D,
557           i.e. excluding C and K. This is exactly what the --ancestry-path
558           option does. Applied to the D..M range, it results in:
559
560                               E-------F
561                                \       \
562                                 G---H---I---J
563                                              \
564                                               L--M
565
566       Before discussing another option, --show-pulls, we need to create a new
567       example history.
568
569       A common problem users face when looking at simplified history is that
570       a commit they know changed a file somehow does not appear in the file’s
571       simplified history. Let’s demonstrate a new example and show how
572       options such as --full-history and --simplify-merges works in that
573       case:
574
575                     .-A---M-----C--N---O---P
576                    /     / \  \  \/   /   /
577                   I     B   \  R-'`-Z'   /
578                    \   /     \/         /
579                     \ /      /\        /
580                      `---X--'  `---Y--'
581
582       For this example, suppose I created file.txt which was modified by A,
583       B, and X in different ways. The single-parent commits C, Z, and Y do
584       not change file.txt. The merge commit M was created by resolving the
585       merge conflict to include both changes from A and B and hence is not
586       TREESAME to either. The merge commit R, however, was created by
587       ignoring the contents of file.txt at M and taking only the contents of
588       file.txt at X. Hence, R is TREESAME to X but not M. Finally, the
589       natural merge resolution to create N is to take the contents of
590       file.txt at R, so N is TREESAME to R but not C. The merge commits O and
591       P are TREESAME to their first parents, but not to their second parents,
592       Z and Y respectively.
593
594       When using the default mode, N and R both have a TREESAME parent, so
595       those edges are walked and the others are ignored. The resulting
596       history graph is:
597
598                   I---X
599
600       When using --full-history, Git walks every edge. This will discover the
601       commits A and B and the merge M, but also will reveal the merge commits
602       O and P. With parent rewriting, the resulting graph is:
603
604                     .-A---M--------N---O---P
605                    /     / \  \  \/   /   /
606                   I     B   \  R-'`--'   /
607                    \   /     \/         /
608                     \ /      /\        /
609                      `---X--'  `------'
610
611       Here, the merge commits O and P contribute extra noise, as they did not
612       actually contribute a change to file.txt. They only merged a topic that
613       was based on an older version of file.txt. This is a common issue in
614       repositories using a workflow where many contributors work in parallel
615       and merge their topic branches along a single trunk: manu unrelated
616       merges appear in the --full-history results.
617
618       When using the --simplify-merges option, the commits O and P disappear
619       from the results. This is because the rewritten second parents of O and
620       P are reachable from their first parents. Those edges are removed and
621       then the commits look like single-parent commits that are TREESAME to
622       their parent. This also happens to the commit N, resulting in a history
623       view as follows:
624
625                     .-A---M--.
626                    /     /    \
627                   I     B      R
628                    \   /      /
629                     \ /      /
630                      `---X--'
631
632       In this view, we see all of the important single-parent changes from A,
633       B, and X. We also see the carefully-resolved merge M and the
634       not-so-carefully-resolved merge R. This is usually enough information
635       to determine why the commits A and B "disappeared" from history in the
636       default view. However, there are a few issues with this approach.
637
638       The first issue is performance. Unlike any previous option, the
639       --simplify-merges option requires walking the entire commit history
640       before returning a single result. This can make the option difficult to
641       use for very large repositories.
642
643       The second issue is one of auditing. When many contributors are working
644       on the same repository, it is important which merge commits introduced
645       a change into an important branch. The problematic merge R above is not
646       likely to be the merge commit that was used to merge into an important
647       branch. Instead, the merge N was used to merge R and X into the
648       important branch. This commit may have information about why the change
649       X came to override the changes from A and B in its commit message.
650
651       --show-pulls
652           In addition to the commits shown in the default history, show each
653           merge commit that is not TREESAME to its first parent but is
654           TREESAME to a later parent.
655
656           When a merge commit is included by --show-pulls, the merge is
657           treated as if it "pulled" the change from another branch. When
658           using --show-pulls on this example (and no other options) the
659           resulting graph is:
660
661                       I---X---R---N
662
663           Here, the merge commits R and N are included because they pulled
664           the commits X and R into the base branch, respectively. These
665           merges are the reason the commits A and B do not appear in the
666           default history.
667
668           When --show-pulls is paired with --simplify-merges, the graph
669           includes all of the necessary information:
670
671                         .-A---M--.   N
672                        /     /    \ /
673                       I     B      R
674                        \   /      /
675                         \ /      /
676                          `---X--'
677
678           Notice that since M is reachable from R, the edge from N to M was
679           simplified away. However, N still appears in the history as an
680           important commit because it "pulled" the change R into the main
681           branch.
682
683       The --simplify-by-decoration option allows you to view only the big
684       picture of the topology of the history, by omitting commits that are
685       not referenced by tags. Commits are marked as !TREESAME (in other
686       words, kept after history simplification rules described above) if (1)
687       they are referenced by tags, or (2) they change the contents of the
688       paths given on the command line. All other commits are marked as
689       TREESAME (subject to be simplified away).
690
691   Bisection Helpers
692       --bisect
693           Limit output to the one commit object which is roughly halfway
694           between included and excluded commits. Note that the bad bisection
695           ref refs/bisect/bad is added to the included commits (if it exists)
696           and the good bisection refs refs/bisect/good-* are added to the
697           excluded commits (if they exist). Thus, supposing there are no refs
698           in refs/bisect/, if
699
700                       $ git rev-list --bisect foo ^bar ^baz
701
702           outputs midpoint, the output of the two commands
703
704                       $ git rev-list foo ^midpoint
705                       $ git rev-list midpoint ^bar ^baz
706
707           would be of roughly the same length. Finding the change which
708           introduces a regression is thus reduced to a binary search:
709           repeatedly generate and test new 'midpoint’s until the commit chain
710           is of length one.
711
712       --bisect-vars
713           This calculates the same as --bisect, except that refs in
714           refs/bisect/ are not used, and except that this outputs text ready
715           to be eval’ed by the shell. These lines will assign the name of the
716           midpoint revision to the variable bisect_rev, and the expected
717           number of commits to be tested after bisect_rev is tested to
718           bisect_nr, the expected number of commits to be tested if
719           bisect_rev turns out to be good to bisect_good, the expected number
720           of commits to be tested if bisect_rev turns out to be bad to
721           bisect_bad, and the number of commits we are bisecting right now to
722           bisect_all.
723
724       --bisect-all
725           This outputs all the commit objects between the included and
726           excluded commits, ordered by their distance to the included and
727           excluded commits. Refs in refs/bisect/ are not used. The farthest
728           from them is displayed first. (This is the only one displayed by
729           --bisect.)
730
731           This is useful because it makes it easy to choose a good commit to
732           test when you want to avoid to test some of them for some reason
733           (they may not compile for example).
734
735           This option can be used along with --bisect-vars, in this case,
736           after all the sorted commit objects, there will be the same text as
737           if --bisect-vars had been used alone.
738
739   Commit Ordering
740       By default, the commits are shown in reverse chronological order.
741
742       --date-order
743           Show no parents before all of its children are shown, but otherwise
744           show commits in the commit timestamp order.
745
746       --author-date-order
747           Show no parents before all of its children are shown, but otherwise
748           show commits in the author timestamp order.
749
750       --topo-order
751           Show no parents before all of its children are shown, and avoid
752           showing commits on multiple lines of history intermixed.
753
754           For example, in a commit history like this:
755
756                   ---1----2----4----7
757                       \              \
758                        3----5----6----8---
759
760           where the numbers denote the order of commit timestamps, git
761           rev-list and friends with --date-order show the commits in the
762           timestamp order: 8 7 6 5 4 3 2 1.
763
764           With --topo-order, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5
765           3 1); some older commits are shown before newer ones in order to
766           avoid showing the commits from two parallel development track mixed
767           together.
768
769       --reverse
770           Output the commits chosen to be shown (see Commit Limiting section
771           above) in reverse order. Cannot be combined with --walk-reflogs.
772
773   Object Traversal
774       These options are mostly targeted for packing of Git repositories.
775
776       --objects
777           Print the object IDs of any object referenced by the listed
778           commits.  --objects foo ^bar thus means “send me all object IDs
779           which I need to download if I have the commit object bar but not
780           foo”.
781
782       --in-commit-order
783           Print tree and blob ids in order of the commits. The tree and blob
784           ids are printed after they are first referenced by a commit.
785
786       --objects-edge
787           Similar to --objects, but also print the IDs of excluded commits
788           prefixed with a “-” character. This is used by git-pack-objects(1)
789           to build a “thin” pack, which records objects in deltified form
790           based on objects contained in these excluded commits to reduce
791           network traffic.
792
793       --objects-edge-aggressive
794           Similar to --objects-edge, but it tries harder to find excluded
795           commits at the cost of increased time. This is used instead of
796           --objects-edge to build “thin” packs for shallow repositories.
797
798       --indexed-objects
799           Pretend as if all trees and blobs used by the index are listed on
800           the command line. Note that you probably want to use --objects,
801           too.
802
803       --unpacked
804           Only useful with --objects; print the object IDs that are not in
805           packs.
806
807       --object-names
808           Only useful with --objects; print the names of the object IDs that
809           are found. This is the default behavior.
810
811       --no-object-names
812           Only useful with --objects; does not print the names of the object
813           IDs that are found. This inverts --object-names. This flag allows
814           the output to be more easily parsed by commands such as git-cat-
815           file(1).
816
817       --filter=<filter-spec>
818           Only useful with one of the --objects*; omits objects (usually
819           blobs) from the list of printed objects. The <filter-spec> may be
820           one of the following:
821
822           The form --filter=blob:none omits all blobs.
823
824           The form --filter=blob:limit=<n>[kmg] omits blobs larger than n
825           bytes or units. n may be zero. The suffixes k, m, and g can be used
826           to name units in KiB, MiB, or GiB. For example, blob:limit=1k is
827           the same as blob:limit=1024.
828
829           The form --filter=sparse:oid=<blob-ish> uses a sparse-checkout
830           specification contained in the blob (or blob-expression) <blob-ish>
831           to omit blobs that would not be not required for a sparse checkout
832           on the requested refs.
833
834           The form --filter=tree:<depth> omits all blobs and trees whose
835           depth from the root tree is >= <depth> (minimum depth if an object
836           is located at multiple depths in the commits traversed). <depth>=0
837           will not include any trees or blobs unless included explicitly in
838           the command-line (or standard input when --stdin is used).
839           <depth>=1 will include only the tree and blobs which are referenced
840           directly by a commit reachable from <commit> or an explicitly-given
841           object. <depth>=2 is like <depth>=1 while also including trees and
842           blobs one more level removed from an explicitly-given commit or
843           tree.
844
845           Note that the form --filter=sparse:path=<path> that wants to read
846           from an arbitrary path on the filesystem has been dropped for
847           security reasons.
848
849           Multiple --filter= flags can be specified to combine filters. Only
850           objects which are accepted by every filter are included.
851
852           The form --filter=combine:<filter1>+<filter2>+...<filterN> can also
853           be used to combined several filters, but this is harder than just
854           repeating the --filter flag and is usually not necessary. Filters
855           are joined by + and individual filters are %-encoded (i.e.
856           URL-encoded). Besides the + and % characters, the following
857           characters are reserved and also must be encoded:
858           ~!@#$^&*()[]{}\;",<>?'` as well as all characters with ASCII code
859           <= 0x20, which includes space and newline.
860
861           Other arbitrary characters can also be encoded. For instance,
862           combine:tree:3+blob:none and combine:tree%3A3+blob%3Anone are
863           equivalent.
864
865       --no-filter
866           Turn off any previous --filter= argument.
867
868       --filter-print-omitted
869           Only useful with --filter=; prints a list of the objects omitted by
870           the filter. Object IDs are prefixed with a “~” character.
871
872       --missing=<missing-action>
873           A debug option to help with future "partial clone" development.
874           This option specifies how missing objects are handled.
875
876           The form --missing=error requests that rev-list stop with an error
877           if a missing object is encountered. This is the default action.
878
879           The form --missing=allow-any will allow object traversal to
880           continue if a missing object is encountered. Missing objects will
881           silently be omitted from the results.
882
883           The form --missing=allow-promisor is like allow-any, but will only
884           allow object traversal to continue for EXPECTED promisor missing
885           objects. Unexpected missing objects will raise an error.
886
887           The form --missing=print is like allow-any, but will also print a
888           list of the missing objects. Object IDs are prefixed with a “?”
889           character.
890
891       --exclude-promisor-objects
892           (For internal use only.) Prefilter object traversal at promisor
893           boundary. This is used with partial clone. This is stronger than
894           --missing=allow-promisor because it limits the traversal, rather
895           than just silencing errors about missing objects.
896
897       --no-walk[=(sorted|unsorted)]
898           Only show the given commits, but do not traverse their ancestors.
899           This has no effect if a range is specified. If the argument
900           unsorted is given, the commits are shown in the order they were
901           given on the command line. Otherwise (if sorted or no argument was
902           given), the commits are shown in reverse chronological order by
903           commit time. Cannot be combined with --graph.
904
905       --do-walk
906           Overrides a previous --no-walk.
907
908   Commit Formatting
909       Using these options, git-rev-list(1) will act similar to the more
910       specialized family of commit log tools: git-log(1), git-show(1), and
911       git-whatchanged(1)
912
913       --pretty[=<format>], --format=<format>
914           Pretty-print the contents of the commit logs in a given format,
915           where <format> can be one of oneline, short, medium, full, fuller,
916           reference, email, raw, format:<string> and tformat:<string>. When
917           <format> is none of the above, and has %placeholder in it, it acts
918           as if --pretty=tformat:<format> were given.
919
920           See the "PRETTY FORMATS" section for some additional details for
921           each format. When =<format> part is omitted, it defaults to medium.
922
923           Note: you can specify the default pretty format in the repository
924           configuration (see git-config(1)).
925
926       --abbrev-commit
927           Instead of showing the full 40-byte hexadecimal commit object name,
928           show a prefix that names the object uniquely. "--abbrev=<n>" (which
929           also modifies diff output, if it is displayed) option can be used
930           to specify the minimum length of the prefix.
931
932           This should make "--pretty=oneline" a whole lot more readable for
933           people using 80-column terminals.
934
935       --no-abbrev-commit
936           Show the full 40-byte hexadecimal commit object name. This negates
937           --abbrev-commit, either explicit or implied by other options such
938           as "--oneline". It also overrides the log.abbrevCommit variable.
939
940       --oneline
941           This is a shorthand for "--pretty=oneline --abbrev-commit" used
942           together.
943
944       --encoding=<encoding>
945           The commit objects record the encoding used for the log message in
946           their encoding header; this option can be used to tell the command
947           to re-code the commit log message in the encoding preferred by the
948           user. For non plumbing commands this defaults to UTF-8. Note that
949           if an object claims to be encoded in X and we are outputting in X,
950           we will output the object verbatim; this means that invalid
951           sequences in the original commit may be copied to the output.
952
953       --expand-tabs=<n>, --expand-tabs, --no-expand-tabs
954           Perform a tab expansion (replace each tab with enough spaces to
955           fill to the next display column that is multiple of <n>) in the log
956           message before showing it in the output.  --expand-tabs is a
957           short-hand for --expand-tabs=8, and --no-expand-tabs is a
958           short-hand for --expand-tabs=0, which disables tab expansion.
959
960           By default, tabs are expanded in pretty formats that indent the log
961           message by 4 spaces (i.e.  medium, which is the default, full, and
962           fuller).
963
964       --show-signature
965           Check the validity of a signed commit object by passing the
966           signature to gpg --verify and show the output.
967
968       --relative-date
969           Synonym for --date=relative.
970
971       --date=<format>
972           Only takes effect for dates shown in human-readable format, such as
973           when using --pretty.  log.date config variable sets a default value
974           for the log command’s --date option. By default, dates are shown in
975           the original time zone (either committer’s or author’s). If -local
976           is appended to the format (e.g., iso-local), the user’s local time
977           zone is used instead.
978
979           --date=relative shows dates relative to the current time, e.g.  “2
980           hours ago”. The -local option has no effect for --date=relative.
981
982           --date=local is an alias for --date=default-local.
983
984           --date=iso (or --date=iso8601) shows timestamps in a ISO 8601-like
985           format. The differences to the strict ISO 8601 format are:
986
987           ·   a space instead of the T date/time delimiter
988
989           ·   a space between time and time zone
990
991           ·   no colon between hours and minutes of the time zone
992
993           --date=iso-strict (or --date=iso8601-strict) shows timestamps in
994           strict ISO 8601 format.
995
996           --date=rfc (or --date=rfc2822) shows timestamps in RFC 2822 format,
997           often found in email messages.
998
999           --date=short shows only the date, but not the time, in YYYY-MM-DD
1000           format.
1001
1002           --date=raw shows the date as seconds since the epoch (1970-01-01
1003           00:00:00 UTC), followed by a space, and then the timezone as an
1004           offset from UTC (a + or - with four digits; the first two are
1005           hours, and the second two are minutes). I.e., as if the timestamp
1006           were formatted with strftime("%s %z")). Note that the -local option
1007           does not affect the seconds-since-epoch value (which is always
1008           measured in UTC), but does switch the accompanying timezone value.
1009
1010           --date=human shows the timezone if the timezone does not match the
1011           current time-zone, and doesn’t print the whole date if that matches
1012           (ie skip printing year for dates that are "this year", but also
1013           skip the whole date itself if it’s in the last few days and we can
1014           just say what weekday it was). For older dates the hour and minute
1015           is also omitted.
1016
1017           --date=unix shows the date as a Unix epoch timestamp (seconds since
1018           1970). As with --raw, this is always in UTC and therefore -local
1019           has no effect.
1020
1021           --date=format:...  feeds the format ...  to your system strftime,
1022           except for %z and %Z, which are handled internally. Use
1023           --date=format:%c to show the date in your system locale’s preferred
1024           format. See the strftime manual for a complete list of format
1025           placeholders. When using -local, the correct syntax is
1026           --date=format-local:....
1027
1028           --date=default is the default format, and is similar to
1029           --date=rfc2822, with a few exceptions:
1030
1031           ·   there is no comma after the day-of-week
1032
1033           ·   the time zone is omitted when the local time zone is used
1034
1035       --header
1036           Print the contents of the commit in raw-format; each record is
1037           separated with a NUL character.
1038
1039       --parents
1040           Print also the parents of the commit (in the form "commit parent...
1041           "). Also enables parent rewriting, see History Simplification
1042           above.
1043
1044       --children
1045           Print also the children of the commit (in the form "commit child...
1046           "). Also enables parent rewriting, see History Simplification
1047           above.
1048
1049       --timestamp
1050           Print the raw commit timestamp.
1051
1052       --left-right
1053           Mark which side of a symmetric difference a commit is reachable
1054           from. Commits from the left side are prefixed with < and those from
1055           the right with >. If combined with --boundary, those commits are
1056           prefixed with -.
1057
1058           For example, if you have this topology:
1059
1060                            y---b---b  branch B
1061                           / \ /
1062                          /   .
1063                         /   / \
1064                        o---x---a---a  branch A
1065
1066           you would get an output like this:
1067
1068                       $ git rev-list --left-right --boundary --pretty=oneline A...B
1069
1070                       >bbbbbbb... 3rd on b
1071                       >bbbbbbb... 2nd on b
1072                       <aaaaaaa... 3rd on a
1073                       <aaaaaaa... 2nd on a
1074                       -yyyyyyy... 1st on b
1075                       -xxxxxxx... 1st on a
1076
1077       --graph
1078           Draw a text-based graphical representation of the commit history on
1079           the left hand side of the output. This may cause extra lines to be
1080           printed in between commits, in order for the graph history to be
1081           drawn properly. Cannot be combined with --no-walk.
1082
1083           This enables parent rewriting, see History Simplification above.
1084
1085           This implies the --topo-order option by default, but the
1086           --date-order option may also be specified.
1087
1088       --show-linear-break[=<barrier>]
1089           When --graph is not used, all history branches are flattened which
1090           can make it hard to see that the two consecutive commits do not
1091           belong to a linear branch. This option puts a barrier in between
1092           them in that case. If <barrier> is specified, it is the string that
1093           will be shown instead of the default one.
1094
1095       --count
1096           Print a number stating how many commits would have been listed, and
1097           suppress all other output. When used together with --left-right,
1098           instead print the counts for left and right commits, separated by a
1099           tab. When used together with --cherry-mark, omit patch equivalent
1100           commits from these counts and print the count for equivalent
1101           commits separated by a tab.
1102

PRETTY FORMATS

1104       If the commit is a merge, and if the pretty-format is not oneline,
1105       email or raw, an additional line is inserted before the Author: line.
1106       This line begins with "Merge: " and the hashes of ancestral commits are
1107       printed, separated by spaces. Note that the listed commits may not
1108       necessarily be the list of the direct parent commits if you have
1109       limited your view of history: for example, if you are only interested
1110       in changes related to a certain directory or file.
1111
1112       There are several built-in formats, and you can define additional
1113       formats by setting a pretty.<name> config option to either another
1114       format name, or a format: string, as described below (see git-
1115       config(1)). Here are the details of the built-in formats:
1116
1117       ·   oneline
1118
1119               <hash> <title line>
1120
1121           This is designed to be as compact as possible.
1122
1123       ·   short
1124
1125               commit <hash>
1126               Author: <author>
1127
1128               <title line>
1129
1130       ·   medium
1131
1132               commit <hash>
1133               Author: <author>
1134               Date:   <author date>
1135
1136               <title line>
1137
1138               <full commit message>
1139
1140       ·   full
1141
1142               commit <hash>
1143               Author: <author>
1144               Commit: <committer>
1145
1146               <title line>
1147
1148               <full commit message>
1149
1150       ·   fuller
1151
1152               commit <hash>
1153               Author:     <author>
1154               AuthorDate: <author date>
1155               Commit:     <committer>
1156               CommitDate: <committer date>
1157
1158               <title line>
1159
1160               <full commit message>
1161
1162       ·   reference
1163
1164               <abbrev hash> (<title line>, <short author date>)
1165
1166           This format is used to refer to another commit in a commit message
1167           and is the same as --pretty='format:%C(auto)%h (%s, %ad)'. By
1168           default, the date is formatted with --date=short unless another
1169           --date option is explicitly specified. As with any format: with
1170           format placeholders, its output is not affected by other options
1171           like --decorate and --walk-reflogs.
1172
1173       ·   email
1174
1175               From <hash> <date>
1176               From: <author>
1177               Date: <author date>
1178               Subject: [PATCH] <title line>
1179
1180               <full commit message>
1181
1182       ·   mboxrd
1183
1184           Like email, but lines in the commit message starting with "From "
1185           (preceded by zero or more ">") are quoted with ">" so they aren’t
1186           confused as starting a new commit.
1187
1188       ·   raw
1189
1190           The raw format shows the entire commit exactly as stored in the
1191           commit object. Notably, the hashes are displayed in full,
1192           regardless of whether --abbrev or --no-abbrev are used, and parents
1193           information show the true parent commits, without taking grafts or
1194           history simplification into account. Note that this format affects
1195           the way commits are displayed, but not the way the diff is shown
1196           e.g. with git log --raw. To get full object names in a raw diff
1197           format, use --no-abbrev.
1198
1199       ·   format:<string>
1200
1201           The format:<string> format allows you to specify which information
1202           you want to show. It works a little bit like printf format, with
1203           the notable exception that you get a newline with %n instead of \n.
1204
1205           E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
1206           would show something like this:
1207
1208               The author of fe6e0ee was Junio C Hamano, 23 hours ago
1209               The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
1210
1211           The placeholders are:
1212
1213           ·   Placeholders that expand to a single literal character:
1214
1215               %n
1216                   newline
1217
1218               %%
1219                   a raw %
1220
1221               %x00
1222                   print a byte from a hex code
1223
1224           ·   Placeholders that affect formatting of later placeholders:
1225
1226               %Cred
1227                   switch color to red
1228
1229               %Cgreen
1230                   switch color to green
1231
1232               %Cblue
1233                   switch color to blue
1234
1235               %Creset
1236                   reset color
1237
1238               %C(...)
1239                   color specification, as described under Values in the
1240                   "CONFIGURATION FILE" section of git-config(1). By default,
1241                   colors are shown only when enabled for log output (by
1242                   color.diff, color.ui, or --color, and respecting the auto
1243                   settings of the former if we are going to a terminal).
1244                   %C(auto,...)  is accepted as a historical synonym for the
1245                   default (e.g., %C(auto,red)). Specifying %C(always,...)
1246                   will show the colors even when color is not otherwise
1247                   enabled (though consider just using --color=always to
1248                   enable color for the whole output, including this format
1249                   and anything else git might color).  auto alone (i.e.
1250                   %C(auto)) will turn on auto coloring on the next
1251                   placeholders until the color is switched again.
1252
1253               %m
1254                   left (<), right (>) or boundary (-) mark
1255
1256               %w([<w>[,<i1>[,<i2>]]])
1257                   switch line wrapping, like the -w option of git-
1258                   shortlog(1).
1259
1260               %<(<N>[,trunc|ltrunc|mtrunc])
1261                   make the next placeholder take at least N columns, padding
1262                   spaces on the right if necessary. Optionally truncate at
1263                   the beginning (ltrunc), the middle (mtrunc) or the end
1264                   (trunc) if the output is longer than N columns. Note that
1265                   truncating only works correctly with N >= 2.
1266
1267               %<|(<N>)
1268                   make the next placeholder take at least until Nth columns,
1269                   padding spaces on the right if necessary
1270
1271               %>(<N>), %>|(<N>)
1272                   similar to %<(<N>), %<|(<N>) respectively, but padding
1273                   spaces on the left
1274
1275               %>>(<N>), %>>|(<N>)
1276                   similar to %>(<N>), %>|(<N>) respectively, except that if
1277                   the next placeholder takes more spaces than given and there
1278                   are spaces on its left, use those spaces
1279
1280               %><(<N>), %><|(<N>)
1281                   similar to %<(<N>), %<|(<N>) respectively, but padding both
1282                   sides (i.e. the text is centered)
1283
1284           ·   Placeholders that expand to information extracted from the
1285               commit:
1286
1287               %H
1288                   commit hash
1289
1290               %h
1291                   abbreviated commit hash
1292
1293               %T
1294                   tree hash
1295
1296               %t
1297                   abbreviated tree hash
1298
1299               %P
1300                   parent hashes
1301
1302               %p
1303                   abbreviated parent hashes
1304
1305               %an
1306                   author name
1307
1308               %aN
1309                   author name (respecting .mailmap, see git-shortlog(1) or
1310                   git-blame(1))
1311
1312               %ae
1313                   author email
1314
1315               %aE
1316                   author email (respecting .mailmap, see git-shortlog(1) or
1317                   git-blame(1))
1318
1319               %al
1320                   author email local-part (the part before the @ sign)
1321
1322               %aL
1323                   author local-part (see %al) respecting .mailmap, see git-
1324                   shortlog(1) or git-blame(1))
1325
1326               %ad
1327                   author date (format respects --date= option)
1328
1329               %aD
1330                   author date, RFC2822 style
1331
1332               %ar
1333                   author date, relative
1334
1335               %at
1336                   author date, UNIX timestamp
1337
1338               %ai
1339                   author date, ISO 8601-like format
1340
1341               %aI
1342                   author date, strict ISO 8601 format
1343
1344               %as
1345                   author date, short format (YYYY-MM-DD)
1346
1347               %cn
1348                   committer name
1349
1350               %cN
1351                   committer name (respecting .mailmap, see git-shortlog(1) or
1352                   git-blame(1))
1353
1354               %ce
1355                   committer email
1356
1357               %cE
1358                   committer email (respecting .mailmap, see git-shortlog(1)
1359                   or git-blame(1))
1360
1361               %cl
1362                   committer email local-part (the part before the @ sign)
1363
1364               %cL
1365                   committer local-part (see %cl) respecting .mailmap, see
1366                   git-shortlog(1) or git-blame(1))
1367
1368               %cd
1369                   committer date (format respects --date= option)
1370
1371               %cD
1372                   committer date, RFC2822 style
1373
1374               %cr
1375                   committer date, relative
1376
1377               %ct
1378                   committer date, UNIX timestamp
1379
1380               %ci
1381                   committer date, ISO 8601-like format
1382
1383               %cI
1384                   committer date, strict ISO 8601 format
1385
1386               %cs
1387                   committer date, short format (YYYY-MM-DD)
1388
1389               %d
1390                   ref names, like the --decorate option of git-log(1)
1391
1392               %D
1393                   ref names without the " (", ")" wrapping.
1394
1395               %S
1396                   ref name given on the command line by which the commit was
1397                   reached (like git log --source), only works with git log
1398
1399               %e
1400                   encoding
1401
1402               %s
1403                   subject
1404
1405               %f
1406                   sanitized subject line, suitable for a filename
1407
1408               %b
1409                   body
1410
1411               %B
1412                   raw body (unwrapped subject and body)
1413
1414               %GG
1415                   raw verification message from GPG for a signed commit
1416
1417               %G?
1418                   show "G" for a good (valid) signature, "B" for a bad
1419                   signature, "U" for a good signature with unknown validity,
1420                   "X" for a good signature that has expired, "Y" for a good
1421                   signature made by an expired key, "R" for a good signature
1422                   made by a revoked key, "E" if the signature cannot be
1423                   checked (e.g. missing key) and "N" for no signature
1424
1425               %GS
1426                   show the name of the signer for a signed commit
1427
1428               %GK
1429                   show the key used to sign a signed commit
1430
1431               %GF
1432                   show the fingerprint of the key used to sign a signed
1433                   commit
1434
1435               %GP
1436                   show the fingerprint of the primary key whose subkey was
1437                   used to sign a signed commit
1438
1439               %GT
1440                   show the trust level for the key used to sign a signed
1441                   commit
1442
1443               %gD
1444                   reflog selector, e.g., refs/stash@{1} or refs/stash@{2
1445                   minutes ago}; the format follows the rules described for
1446                   the -g option. The portion before the @ is the refname as
1447                   given on the command line (so git log -g refs/heads/master
1448                   would yield refs/heads/master@{0}).
1449
1450               %gd
1451                   shortened reflog selector; same as %gD, but the refname
1452                   portion is shortened for human readability (so
1453                   refs/heads/master becomes just master).
1454
1455               %gn
1456                   reflog identity name
1457
1458               %gN
1459                   reflog identity name (respecting .mailmap, see git-
1460                   shortlog(1) or git-blame(1))
1461
1462               %ge
1463                   reflog identity email
1464
1465               %gE
1466                   reflog identity email (respecting .mailmap, see git-
1467                   shortlog(1) or git-blame(1))
1468
1469               %gs
1470                   reflog subject
1471
1472               %(trailers[:options])
1473                   display the trailers of the body as interpreted by git-
1474                   interpret-trailers(1). The trailers string may be followed
1475                   by a colon and zero or more comma-separated options:
1476
1477                   ·   key=<K>: only show trailers with specified key.
1478                       Matching is done case-insensitively and trailing colon
1479                       is optional. If option is given multiple times trailer
1480                       lines matching any of the keys are shown. This option
1481                       automatically enables the only option so that
1482                       non-trailer lines in the trailer block are hidden. If
1483                       that is not desired it can be disabled with only=false.
1484                       E.g., %(trailers:key=Reviewed-by) shows trailer lines
1485                       with key Reviewed-by.
1486
1487                   ·   only[=val]: select whether non-trailer lines from the
1488                       trailer block should be included. The only keyword may
1489                       optionally be followed by an equal sign and one of
1490                       true, on, yes to omit or false, off, no to show the
1491                       non-trailer lines. If option is given without value it
1492                       is enabled. If given multiple times the last value is
1493                       used.
1494
1495                   ·   separator=<SEP>: specify a separator inserted between
1496                       trailer lines. When this option is not given each
1497                       trailer line is terminated with a line feed character.
1498                       The string SEP may contain the literal formatting codes
1499                       described above. To use comma as separator one must use
1500                       %x2C as it would otherwise be parsed as next option. If
1501                       separator option is given multiple times only the last
1502                       one is used. E.g., %(trailers:key=Ticket,separator=%x2C
1503                       ) shows all trailer lines whose key is "Ticket"
1504                       separated by a comma and a space.
1505
1506                   ·   unfold[=val]: make it behave as if interpret-trailer’s
1507                       --unfold option was given. In same way as to for only
1508                       it can be followed by an equal sign and explicit value.
1509                       E.g., %(trailers:only,unfold=true) unfolds and shows
1510                       all trailer lines.
1511
1512                   ·   valueonly[=val]: skip over the key part of the trailer
1513                       line and only show the value part. Also this optionally
1514                       allows explicit value.
1515
1516           Note
1517           Some placeholders may depend on other options given to the revision
1518           traversal engine. For example, the %g* reflog options will insert
1519           an empty string unless we are traversing reflog entries (e.g., by
1520           git log -g). The %d and %D placeholders will use the "short"
1521           decoration format if --decorate was not already provided on the
1522           command line.
1523
1524       If you add a + (plus sign) after % of a placeholder, a line-feed is
1525       inserted immediately before the expansion if and only if the
1526       placeholder expands to a non-empty string.
1527
1528       If you add a - (minus sign) after % of a placeholder, all consecutive
1529       line-feeds immediately preceding the expansion are deleted if and only
1530       if the placeholder expands to an empty string.
1531
1532       If you add a ` ` (space) after % of a placeholder, a space is inserted
1533       immediately before the expansion if and only if the placeholder expands
1534       to a non-empty string.
1535
1536       ·   tformat:
1537
1538           The tformat: format works exactly like format:, except that it
1539           provides "terminator" semantics instead of "separator" semantics.
1540           In other words, each commit has the message terminator character
1541           (usually a newline) appended, rather than a separator placed
1542           between entries. This means that the final entry of a single-line
1543           format will be properly terminated with a new line, just as the
1544           "oneline" format does. For example:
1545
1546               $ git log -2 --pretty=format:%h 4da45bef \
1547                 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
1548               4da45be
1549               7134973 -- NO NEWLINE
1550
1551               $ git log -2 --pretty=tformat:%h 4da45bef \
1552                 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
1553               4da45be
1554               7134973
1555
1556           In addition, any unrecognized string that has a % in it is
1557           interpreted as if it has tformat: in front of it. For example,
1558           these two are equivalent:
1559
1560               $ git log -2 --pretty=tformat:%h 4da45bef
1561               $ git log -2 --pretty=%h 4da45bef
1562

GIT

1564       Part of the git(1) suite
1565
1566
1567
1568Git 2.30.2                        2021-03-08                   GIT-REV-LIST(1)
Impressum