1GIT-REV-LIST(1) Git Manual GIT-REV-LIST(1)
2
6 git-rev-list - Lists commit objects in reverse chronological order
7
9 git rev-list [<options>] <commit>... [[--] <path>...]
10
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 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 Thus, the following command:
25 $ git rev-list foo bar ^baz
27 means "list all the commits which are reachable from foo or bar, but
29 not from baz".
30 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 $ git rev-list origin..HEAD
36 $ git rev-list HEAD ^origin
37 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 $ git rev-list A B --not $(git merge-base --all A B)
43 $ git rev-list A...B
44 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
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 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 Note that these are applied before commit ordering and formatting
62 options, such as --reverse.
63 -<number>, -n <number>, --max-count=<number>
65 Limit the number of commits to output.
66 --skip=<number>
68 Skip number commits before starting to show the commit output.
69 --since=<date>, --after=<date>
71 Show commits more recent than a specific date.
72 --until=<date>, --before=<date>
74 Show commits older than a specific date.
75 --max-age=<timestamp>, --min-age=<timestamp>
77 Limit the commits output to specified time range.
78 --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 --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 --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 --all-match
100 Limit the commits output to ones that match all given --grep,
101 instead of ones that match at least one.
102 --invert-grep
104 Limit the commits output to ones with log message that do not match
105 the pattern specified with --grep=<pattern>.
106 -i, --regexp-ignore-case
108 Match the regular expression limiting patterns without regard to
109 letter case.
110 --basic-regexp
112 Consider the limiting patterns to be basic regular expressions;
113 this is the default.
114 -E, --extended-regexp
116 Consider the limiting patterns to be extended regular expressions
117 instead of the default basic regular expressions.
118 -F, --fixed-strings
120 Consider the limiting patterns to be fixed strings (don’t interpret
121 pattern as a regular expression).
122 -P, --perl-regexp
124 Consider the limiting patterns to be Perl-compatible regular
125 expressions.
126 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 --remove-empty
132 Stop when a given path disappears from the tree.
133 --merges
135 Print only merge commits. This is exactly the same as
136 --min-parents=2.
137 --no-merges
139 Do not print commits with more than one parent. This is exactly the
140 same as --max-parents=1.
141 --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 --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 --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 --not
163 Reverses the meaning of the ^ prefix (or lack thereof) for all
164 following revision specifiers, up to the next --not.
165 --all
167 Pretend as if all the refs in refs/, along with HEAD, are listed on
168 the command line as <commit>.
169 --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 --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 --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 --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 --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 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 --reflog
208 Pretend as if all objects mentioned by reflogs are listed on the
209 command line as <commit>.
210 --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 --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 --ignore-missing
225 Upon seeing an invalid object name in the input, pretend as if the
226 bad input was not given.
227 --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 --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 --disk-usage
241 Suppress normal output; instead, print the sum of the bytes used
242 for on-disk storage by the selected commits or objects. This is
243 equivalent to piping the output into git cat-file
244 --batch-check='%(objectsize:disk)', except that it runs much faster
245 (especially with --use-bitmap-index). See the CAVEATS section in
246 git-cat-file(1) for the limitations of what "on-disk storage"
247 means.
248 --cherry-mark
250 Like --cherry-pick (see below) but mark equivalent commits with =
251 rather than omitting them, and inequivalent ones with +.
252 --cherry-pick
254 Omit any commit that introduces the same change as another commit
255 on the “other side” when the set of commits are limited with
256 symmetric difference.
257 For example, if you have two branches, A and B, a usual way to list
259 all commits on only one side of them is with --left-right (see the
260 example below in the description of the --left-right option).
261 However, it shows the commits that were cherry-picked from the
262 other branch (for example, “3rd on b” may be cherry-picked from
263 branch A). With this option, such pairs of commits are excluded
264 from the output.
265 --left-only, --right-only
267 List only commits on the respective side of a symmetric difference,
268 i.e. only those which would be marked < resp. > by --left-right.
269 For example, --cherry-pick --right-only A...B omits those commits
271 from B which are in A or are patch-equivalent to a commit in A. In
272 other words, this lists the + commits from git cherry A B. More
273 precisely, --cherry-pick --right-only --no-merges gives the exact
274 list.
275 --cherry
277 A synonym for --right-only --cherry-mark --no-merges; useful to
278 limit the output to the commits on our side and mark those that
279 have been applied to the other side of a forked history with git
280 log --cherry upstream...mybranch, similar to git cherry upstream
281 mybranch.
282 -g, --walk-reflogs
284 Instead of walking the commit ancestry chain, walk reflog entries
285 from the most recent one to older ones. When this option is used
286 you cannot specify commits to exclude (that is, ^commit,
287 commit1..commit2, and commit1...commit2 notations cannot be used).
288 With --pretty format other than oneline and reference (for obvious
290 reasons), this causes the output to have two extra lines of
291 information taken from the reflog. The reflog designator in the
292 output may be shown as ref@{Nth} (where Nth is the
293 reverse-chronological index in the reflog) or as ref@{timestamp}
294 (with the timestamp for that entry), depending on a few rules:
295 1. If the starting point is specified as ref@{Nth}, show the index
297 format.
298 2. If the starting point was specified as ref@{now}, show the
300 timestamp format.
301 3. If neither was used, but --date was given on the command line,
303 show the timestamp in the format requested by --date.
304 4. Otherwise, show the index format.
306 Under --pretty=oneline, the commit message is prefixed with this
308 information on the same line. This option cannot be combined with
309 --reverse. See also git-reflog(1).
310 Under --pretty=reference, this information will not be shown at
312 all.
313 --merge
315 After a failed merge, show refs that touch files having a conflict
316 and don’t exist on all heads to merge.
317 --boundary
319 Output excluded boundary commits. Boundary commits are prefixed
320 with -.
321 --use-bitmap-index
323 Try to speed up the traversal using the pack bitmap index (if one
324 is available). Note that when traversing with --objects, trees and
325 blobs will not have their associated path printed.
326 --progress=<header>
328 Show progress reports on stderr as objects are considered. The
329 <header> text will be printed with each progress update.
330 History Simplification
332 Sometimes you are only interested in parts of the history, for example
333 the commits modifying a particular <path>. But there are two parts of
334 History Simplification, one part is selecting the commits and the other
335 is how to do it, as there are various strategies to simplify the
336 history.
337 The following options select the commits to be shown:
339 <paths>
341 Commits modifying the given <paths> are selected.
342 --simplify-by-decoration
344 Commits that are referred by some branch or tag are selected.
345 Note that extra commits can be shown to give a meaningful history.
347 The following options affect the way the simplification is performed:
349 Default mode
351 Simplifies the history to the simplest history explaining the final
352 state of the tree. Simplest because it prunes some side branches if
353 the end result is the same (i.e. merging branches with the same
354 content)
355 --show-pulls
357 Include all commits from the default mode, but also any merge
358 commits that are not TREESAME to the first parent but are TREESAME
359 to a later parent. This mode is helpful for showing the merge
360 commits that "first introduced" a change to a branch.
361 --full-history
363 Same as the default mode, but does not prune some history.
364 --dense
366 Only the selected commits are shown, plus some to have a meaningful
367 history.
368 --sparse
370 All commits in the simplified history are shown.
371 --simplify-merges
373 Additional option to --full-history to remove some needless merges
374 from the resulting history, as there are no selected commits
375 contributing to this merge.
376 --ancestry-path
378 When given a range of commits to display (e.g. commit1..commit2 or
379 commit2 ^commit1), only display commits that exist directly on the
380 ancestry chain between the commit1 and commit2, i.e. commits that
381 are both descendants of commit1, and ancestors of commit2.
382 A more detailed explanation follows.
384 Suppose you specified foo as the <paths>. We shall call commits that
386 modify foo !TREESAME, and the rest TREESAME. (In a diff filtered for
387 foo, they look different and equal, respectively.)
388 In the following, we will always refer to the same example history to
390 illustrate the differences between simplification settings. We assume
391 that you are filtering for a file foo in this commit graph:
392 .-A---M---N---O---P---Q
394 / / / / / /
395 I B C D E Y
396 \ / / / / /
397 `-------------' X
398 The horizontal line of history A---Q is taken to be the first parent of
400 each merge. The commits are:
401 • I is the initial commit, in which foo exists with contents “asdf”,
403 and a file quux exists with contents “quux”. Initial commits are
404 compared to an empty tree, so I is !TREESAME.
405 • In A, foo contains just “foo”.
407 • B contains the same change as A. Its merge M is trivial and hence
409 TREESAME to all parents.
410 • C does not change foo, but its merge N changes it to “foobar”, so
412 it is not TREESAME to any parent.
413 • D sets foo to “baz”. Its merge O combines the strings from N and D
415 to “foobarbaz”; i.e., it is not TREESAME to any parent.
416 • E changes quux to “xyzzy”, and its merge P combines the strings to
418 “quux xyzzy”. P is TREESAME to O, but not to E.
419 • X is an independent root commit that added a new file side, and Y
421 modified it. Y is TREESAME to X. Its merge Q added side to P, and
422 Q is TREESAME to P, but not to Y.
423 rev-list walks backwards through history, including or excluding
425 commits based on whether --full-history and/or parent rewriting (via
426 --parents or --children) are used. The following settings are
427 available.
428 Default mode
430 Commits are included if they are not TREESAME to any parent (though
431 this can be changed, see --sparse below). If the commit was a
432 merge, and it was TREESAME to one parent, follow only that parent.
433 (Even if there are several TREESAME parents, follow only one of
434 them.) Otherwise, follow all parents.
435 This results in:
437 .-A---N---O
439 / / /
440 I---------D
441 Note how the rule to only follow the TREESAME parent, if one is
443 available, removed B from consideration entirely. C was considered
444 via N, but is TREESAME. Root commits are compared to an empty tree,
445 so I is !TREESAME.
446 Parent/child relations are only visible with --parents, but that
448 does not affect the commits selected in default mode, so we have
449 shown the parent lines.
450 --full-history without parent rewriting
452 This mode differs from the default in one point: always follow all
453 parents of a merge, even if it is TREESAME to one of them. Even if
454 more than one side of the merge has commits that are included, this
455 does not imply that the merge itself is! In the example, we get
456 I A B N D O P Q
458 M was excluded because it is TREESAME to both parents. E, C and B
460 were all walked, but only B was !TREESAME, so the others do not
461 appear.
462 Note that without parent rewriting, it is not really possible to
464 talk about the parent/child relationships between the commits, so
465 we show them disconnected.
466 --full-history with parent rewriting
468 Ordinary commits are only included if they are !TREESAME (though
469 this can be changed, see --sparse below).
470 Merges are always included. However, their parent list is
472 rewritten: Along each parent, prune away commits that are not
473 included themselves. This results in
474 .-A---M---N---O---P---Q
476 / / / / /
477 I B / D /
478 \ / / / /
479 `-------------'
480 Compare to --full-history without rewriting above. Note that E was
482 pruned away because it is TREESAME, but the parent list of P was
483 rewritten to contain E's parent I. The same happened for C and N,
484 and X, Y and Q.
485 In addition to the above settings, you can change whether TREESAME
487 affects inclusion:
488 --dense
490 Commits that are walked are included if they are not TREESAME to
491 any parent.
492 --sparse
494 All commits that are walked are included.
495 Note that without --full-history, this still simplifies merges: if
497 one of the parents is TREESAME, we follow only that one, so the
498 other sides of the merge are never walked.
499 --simplify-merges
501 First, build a history graph in the same way that --full-history
502 with parent rewriting does (see above).
503 Then simplify each commit C to its replacement C' in the final
505 history according to the following rules:
506 • Set C' to C.
508 • Replace each parent P of C' with its simplification P'. In the
510 process, drop parents that are ancestors of other parents or
511 that are root commits TREESAME to an empty tree, and remove
512 duplicates, but take care to never drop all parents that we are
513 TREESAME to.
514 • If after this parent rewriting, C' is a root or merge commit
516 (has zero or >1 parents), a boundary commit, or !TREESAME, it
517 remains. Otherwise, it is replaced with its only parent.
518 The effect of this is best shown by way of comparing to
520 --full-history with parent rewriting. The example turns into:
521 .-A---M---N---O
523 / / /
524 I B D
525 \ / /
526 `---------'
527 Note the major differences in N, P, and Q over --full-history:
529 • N's parent list had I removed, because it is an ancestor of the
531 other parent M. Still, N remained because it is !TREESAME.
532 • P's parent list similarly had I removed. P was then removed
534 completely, because it had one parent and is TREESAME.
535 • Q's parent list had Y simplified to X. X was then removed,
537 because it was a TREESAME root. Q was then removed completely,
538 because it had one parent and is TREESAME.
539 There is another simplification mode available:
541 --ancestry-path
543 Limit the displayed commits to those directly on the ancestry chain
544 between the “from” and “to” commits in the given commit range. I.e.
545 only display commits that are ancestor of the “to” commit and
546 descendants of the “from” commit.
547 As an example use case, consider the following commit history:
549 D---E-------F
551 / \ \
552 B---C---G---H---I---J
553 / \
554 A-------K---------------L--M
555 A regular D..M computes the set of commits that are ancestors of M,
557 but excludes the ones that are ancestors of D. This is useful to
558 see what happened to the history leading to M since D, in the sense
559 that “what does M have that did not exist in D”. The result in this
560 example would be all the commits, except A and B (and D itself, of
561 course).
562 When we want to find out what commits in M are contaminated with
564 the bug introduced by D and need fixing, however, we might want to
565 view only the subset of D..M that are actually descendants of D,
566 i.e. excluding C and K. This is exactly what the --ancestry-path
567 option does. Applied to the D..M range, it results in:
568 E-------F
570 \ \
571 G---H---I---J
572 \
573 L--M
574 Before discussing another option, --show-pulls, we need to create a new
576 example history.
577 A common problem users face when looking at simplified history is that
579 a commit they know changed a file somehow does not appear in the file’s
580 simplified history. Let’s demonstrate a new example and show how
581 options such as --full-history and --simplify-merges works in that
582 case:
583 .-A---M-----C--N---O---P
585 / / \ \ \/ / /
586 I B \ R-'`-Z' /
587 \ / \/ /
588 \ / /\ /
589 `---X--' `---Y--'
590 For this example, suppose I created file.txt which was modified by A,
592 B, and X in different ways. The single-parent commits C, Z, and Y do
593 not change file.txt. The merge commit M was created by resolving the
594 merge conflict to include both changes from A and B and hence is not
595 TREESAME to either. The merge commit R, however, was created by
596 ignoring the contents of file.txt at M and taking only the contents of
597 file.txt at X. Hence, R is TREESAME to X but not M. Finally, the
598 natural merge resolution to create N is to take the contents of
599 file.txt at R, so N is TREESAME to R but not C. The merge commits O and
600 P are TREESAME to their first parents, but not to their second parents,
601 Z and Y respectively.
602 When using the default mode, N and R both have a TREESAME parent, so
604 those edges are walked and the others are ignored. The resulting
605 history graph is:
606 I---X
608 When using --full-history, Git walks every edge. This will discover the
610 commits A and B and the merge M, but also will reveal the merge commits
611 O and P. With parent rewriting, the resulting graph is:
612 .-A---M--------N---O---P
614 / / \ \ \/ / /
615 I B \ R-'`--' /
616 \ / \/ /
617 \ / /\ /
618 `---X--' `------'
619 Here, the merge commits O and P contribute extra noise, as they did not
621 actually contribute a change to file.txt. They only merged a topic that
622 was based on an older version of file.txt. This is a common issue in
623 repositories using a workflow where many contributors work in parallel
624 and merge their topic branches along a single trunk: manu unrelated
625 merges appear in the --full-history results.
626 When using the --simplify-merges option, the commits O and P disappear
628 from the results. This is because the rewritten second parents of O and
629 P are reachable from their first parents. Those edges are removed and
630 then the commits look like single-parent commits that are TREESAME to
631 their parent. This also happens to the commit N, resulting in a history
632 view as follows:
633 .-A---M--.
635 / / \
636 I B R
637 \ / /
638 \ / /
639 `---X--'
640 In this view, we see all of the important single-parent changes from A,
642 B, and X. We also see the carefully-resolved merge M and the
643 not-so-carefully-resolved merge R. This is usually enough information
644 to determine why the commits A and B "disappeared" from history in the
645 default view. However, there are a few issues with this approach.
646 The first issue is performance. Unlike any previous option, the
648 --simplify-merges option requires walking the entire commit history
649 before returning a single result. This can make the option difficult to
650 use for very large repositories.
651 The second issue is one of auditing. When many contributors are working
653 on the same repository, it is important which merge commits introduced
654 a change into an important branch. The problematic merge R above is not
655 likely to be the merge commit that was used to merge into an important
656 branch. Instead, the merge N was used to merge R and X into the
657 important branch. This commit may have information about why the change
658 X came to override the changes from A and B in its commit message.
659 --show-pulls
661 In addition to the commits shown in the default history, show each
662 merge commit that is not TREESAME to its first parent but is
663 TREESAME to a later parent.
664 When a merge commit is included by --show-pulls, the merge is
666 treated as if it "pulled" the change from another branch. When
667 using --show-pulls on this example (and no other options) the
668 resulting graph is:
669 I---X---R---N
671 Here, the merge commits R and N are included because they pulled
673 the commits X and R into the base branch, respectively. These
674 merges are the reason the commits A and B do not appear in the
675 default history.
676 When --show-pulls is paired with --simplify-merges, the graph
678 includes all of the necessary information:
679 .-A---M--. N
681 / / \ /
682 I B R
683 \ / /
684 \ / /
685 `---X--'
686 Notice that since M is reachable from R, the edge from N to M was
688 simplified away. However, N still appears in the history as an
689 important commit because it "pulled" the change R into the main
690 branch.
691 The --simplify-by-decoration option allows you to view only the big
693 picture of the topology of the history, by omitting commits that are
694 not referenced by tags. Commits are marked as !TREESAME (in other
695 words, kept after history simplification rules described above) if (1)
696 they are referenced by tags, or (2) they change the contents of the
697 paths given on the command line. All other commits are marked as
698 TREESAME (subject to be simplified away).
699 Bisection Helpers
701 --bisect
702 Limit output to the one commit object which is roughly halfway
703 between included and excluded commits. Note that the bad bisection
704 ref refs/bisect/bad is added to the included commits (if it exists)
705 and the good bisection refs refs/bisect/good-* are added to the
706 excluded commits (if they exist). Thus, supposing there are no refs
707 in refs/bisect/, if
708 $ git rev-list --bisect foo ^bar ^baz
710 outputs midpoint, the output of the two commands
712 $ git rev-list foo ^midpoint
714 $ git rev-list midpoint ^bar ^baz
715 would be of roughly the same length. Finding the change which
717 introduces a regression is thus reduced to a binary search:
718 repeatedly generate and test new 'midpoint’s until the commit chain
719 is of length one.
720 --bisect-vars
722 This calculates the same as --bisect, except that refs in
723 refs/bisect/ are not used, and except that this outputs text ready
724 to be eval’ed by the shell. These lines will assign the name of the
725 midpoint revision to the variable bisect_rev, and the expected
726 number of commits to be tested after bisect_rev is tested to
727 bisect_nr, the expected number of commits to be tested if
728 bisect_rev turns out to be good to bisect_good, the expected number
729 of commits to be tested if bisect_rev turns out to be bad to
730 bisect_bad, and the number of commits we are bisecting right now to
731 bisect_all.
732 --bisect-all
734 This outputs all the commit objects between the included and
735 excluded commits, ordered by their distance to the included and
736 excluded commits. Refs in refs/bisect/ are not used. The farthest
737 from them is displayed first. (This is the only one displayed by
738 --bisect.)
739 This is useful because it makes it easy to choose a good commit to
741 test when you want to avoid to test some of them for some reason
742 (they may not compile for example).
743 This option can be used along with --bisect-vars, in this case,
745 after all the sorted commit objects, there will be the same text as
746 if --bisect-vars had been used alone.
747 Commit Ordering
749 By default, the commits are shown in reverse chronological order.
750 --date-order
752 Show no parents before all of its children are shown, but otherwise
753 show commits in the commit timestamp order.
754 --author-date-order
756 Show no parents before all of its children are shown, but otherwise
757 show commits in the author timestamp order.
758 --topo-order
760 Show no parents before all of its children are shown, and avoid
761 showing commits on multiple lines of history intermixed.
762 For example, in a commit history like this:
764 ---1----2----4----7
766 \ \
767 3----5----6----8---
768 where the numbers denote the order of commit timestamps, git
770 rev-list and friends with --date-order show the commits in the
771 timestamp order: 8 7 6 5 4 3 2 1.
772 With --topo-order, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5
774 3 1); some older commits are shown before newer ones in order to
775 avoid showing the commits from two parallel development track mixed
776 together.
777 --reverse
779 Output the commits chosen to be shown (see Commit Limiting section
780 above) in reverse order. Cannot be combined with --walk-reflogs.
781 Object Traversal
783 These options are mostly targeted for packing of Git repositories.
784 --objects
786 Print the object IDs of any object referenced by the listed
787 commits. --objects foo ^bar thus means “send me all object IDs
788 which I need to download if I have the commit object bar but not
789 foo”.
790 --in-commit-order
792 Print tree and blob ids in order of the commits. The tree and blob
793 ids are printed after they are first referenced by a commit.
794 --objects-edge
796 Similar to --objects, but also print the IDs of excluded commits
797 prefixed with a “-” character. This is used by git-pack-objects(1)
798 to build a “thin” pack, which records objects in deltified form
799 based on objects contained in these excluded commits to reduce
800 network traffic.
801 --objects-edge-aggressive
803 Similar to --objects-edge, but it tries harder to find excluded
804 commits at the cost of increased time. This is used instead of
805 --objects-edge to build “thin” packs for shallow repositories.
806 --indexed-objects
808 Pretend as if all trees and blobs used by the index are listed on
809 the command line. Note that you probably want to use --objects,
810 too.
811 --unpacked
813 Only useful with --objects; print the object IDs that are not in
814 packs.
815 --object-names
817 Only useful with --objects; print the names of the object IDs that
818 are found. This is the default behavior.
819 --no-object-names
821 Only useful with --objects; does not print the names of the object
822 IDs that are found. This inverts --object-names. This flag allows
823 the output to be more easily parsed by commands such as git-cat-
824 file(1).
825 --filter=<filter-spec>
827 Only useful with one of the --objects*; omits objects (usually
828 blobs) from the list of printed objects. The <filter-spec> may be
829 one of the following:
830 The form --filter=blob:none omits all blobs.
832 The form --filter=blob:limit=<n>[kmg] omits blobs larger than n
834 bytes or units. n may be zero. The suffixes k, m, and g can be used
835 to name units in KiB, MiB, or GiB. For example, blob:limit=1k is
836 the same as blob:limit=1024.
837 The form --filter=sparse:oid=<blob-ish> uses a sparse-checkout
839 specification contained in the blob (or blob-expression) <blob-ish>
840 to omit blobs that would not be not required for a sparse checkout
841 on the requested refs.
842 The form --filter=tree:<depth> omits all blobs and trees whose
844 depth from the root tree is >= <depth> (minimum depth if an object
845 is located at multiple depths in the commits traversed). <depth>=0
846 will not include any trees or blobs unless included explicitly in
847 the command-line (or standard input when --stdin is used).
848 <depth>=1 will include only the tree and blobs which are referenced
849 directly by a commit reachable from <commit> or an explicitly-given
850 object. <depth>=2 is like <depth>=1 while also including trees and
851 blobs one more level removed from an explicitly-given commit or
852 tree.
853 Note that the form --filter=sparse:path=<path> that wants to read
855 from an arbitrary path on the filesystem has been dropped for
856 security reasons.
857 Multiple --filter= flags can be specified to combine filters. Only
859 objects which are accepted by every filter are included.
860 The form --filter=combine:<filter1>+<filter2>+...<filterN> can also
862 be used to combined several filters, but this is harder than just
863 repeating the --filter flag and is usually not necessary. Filters
864 are joined by + and individual filters are %-encoded (i.e.
865 URL-encoded). Besides the + and % characters, the following
866 characters are reserved and also must be encoded:
867 ~!@#$^&*()[]{}\;",<>?'` as well as all characters with ASCII code
868 <= 0x20, which includes space and newline.
869 Other arbitrary characters can also be encoded. For instance,
871 combine:tree:3+blob:none and combine:tree%3A3+blob%3Anone are
872 equivalent.
873 --no-filter
875 Turn off any previous --filter= argument.
876 --filter-print-omitted
878 Only useful with --filter=; prints a list of the objects omitted by
879 the filter. Object IDs are prefixed with a “~” character.
880 --missing=<missing-action>
882 A debug option to help with future "partial clone" development.
883 This option specifies how missing objects are handled.
884 The form --missing=error requests that rev-list stop with an error
886 if a missing object is encountered. This is the default action.
887 The form --missing=allow-any will allow object traversal to
889 continue if a missing object is encountered. Missing objects will
890 silently be omitted from the results.
891 The form --missing=allow-promisor is like allow-any, but will only
893 allow object traversal to continue for EXPECTED promisor missing
894 objects. Unexpected missing objects will raise an error.
895 The form --missing=print is like allow-any, but will also print a
897 list of the missing objects. Object IDs are prefixed with a “?”
898 character.
899 --exclude-promisor-objects
901 (For internal use only.) Prefilter object traversal at promisor
902 boundary. This is used with partial clone. This is stronger than
903 --missing=allow-promisor because it limits the traversal, rather
904 than just silencing errors about missing objects.
905 --no-walk[=(sorted|unsorted)]
907 Only show the given commits, but do not traverse their ancestors.
908 This has no effect if a range is specified. If the argument
909 unsorted is given, the commits are shown in the order they were
910 given on the command line. Otherwise (if sorted or no argument was
911 given), the commits are shown in reverse chronological order by
912 commit time. Cannot be combined with --graph.
913 --do-walk
915 Overrides a previous --no-walk.
916 Commit Formatting
918 Using these options, git-rev-list(1) will act similar to the more
919 specialized family of commit log tools: git-log(1), git-show(1), and
920 git-whatchanged(1)
921 --pretty[=<format>], --format=<format>
923 Pretty-print the contents of the commit logs in a given format,
924 where <format> can be one of oneline, short, medium, full, fuller,
925 reference, email, raw, format:<string> and tformat:<string>. When
926 <format> is none of the above, and has %placeholder in it, it acts
927 as if --pretty=tformat:<format> were given.
928 See the "PRETTY FORMATS" section for some additional details for
930 each format. When =<format> part is omitted, it defaults to medium.
931 Note: you can specify the default pretty format in the repository
933 configuration (see git-config(1)).
934 --abbrev-commit
936 Instead of showing the full 40-byte hexadecimal commit object name,
937 show a prefix that names the object uniquely. "--abbrev=<n>" (which
938 also modifies diff output, if it is displayed) option can be used
939 to specify the minimum length of the prefix.
940 This should make "--pretty=oneline" a whole lot more readable for
942 people using 80-column terminals.
943 --no-abbrev-commit
945 Show the full 40-byte hexadecimal commit object name. This negates
946 --abbrev-commit, either explicit or implied by other options such
947 as "--oneline". It also overrides the log.abbrevCommit variable.
948 --oneline
950 This is a shorthand for "--pretty=oneline --abbrev-commit" used
951 together.
952 --encoding=<encoding>
954 The commit objects record the encoding used for the log message in
955 their encoding header; this option can be used to tell the command
956 to re-code the commit log message in the encoding preferred by the
957 user. For non plumbing commands this defaults to UTF-8. Note that
958 if an object claims to be encoded in X and we are outputting in X,
959 we will output the object verbatim; this means that invalid
960 sequences in the original commit may be copied to the output.
961 --expand-tabs=<n>, --expand-tabs, --no-expand-tabs
963 Perform a tab expansion (replace each tab with enough spaces to
964 fill to the next display column that is multiple of <n>) in the log
965 message before showing it in the output. --expand-tabs is a
966 short-hand for --expand-tabs=8, and --no-expand-tabs is a
967 short-hand for --expand-tabs=0, which disables tab expansion.
968 By default, tabs are expanded in pretty formats that indent the log
970 message by 4 spaces (i.e. medium, which is the default, full, and
971 fuller).
972 --show-signature
974 Check the validity of a signed commit object by passing the
975 signature to gpg --verify and show the output.
976 --relative-date
978 Synonym for --date=relative.
979 --date=<format>
981 Only takes effect for dates shown in human-readable format, such as
982 when using --pretty. log.date config variable sets a default value
983 for the log command’s --date option. By default, dates are shown in
984 the original time zone (either committer’s or author’s). If -local
985 is appended to the format (e.g., iso-local), the user’s local time
986 zone is used instead.
987 --date=relative shows dates relative to the current time, e.g. “2
989 hours ago”. The -local option has no effect for --date=relative.
990 --date=local is an alias for --date=default-local.
992 --date=iso (or --date=iso8601) shows timestamps in a ISO 8601-like
994 format. The differences to the strict ISO 8601 format are:
995 • a space instead of the T date/time delimiter
997 • a space between time and time zone
999 • no colon between hours and minutes of the time zone
1001 --date=iso-strict (or --date=iso8601-strict) shows timestamps in
1003 strict ISO 8601 format.
1004 --date=rfc (or --date=rfc2822) shows timestamps in RFC 2822 format,
1006 often found in email messages.
1007 --date=short shows only the date, but not the time, in YYYY-MM-DD
1009 format.
1010 --date=raw shows the date as seconds since the epoch (1970-01-01
1012 00:00:00 UTC), followed by a space, and then the timezone as an
1013 offset from UTC (a + or - with four digits; the first two are
1014 hours, and the second two are minutes). I.e., as if the timestamp
1015 were formatted with strftime("%s %z")). Note that the -local option
1016 does not affect the seconds-since-epoch value (which is always
1017 measured in UTC), but does switch the accompanying timezone value.
1018 --date=human shows the timezone if the timezone does not match the
1020 current time-zone, and doesn’t print the whole date if that matches
1021 (ie skip printing year for dates that are "this year", but also
1022 skip the whole date itself if it’s in the last few days and we can
1023 just say what weekday it was). For older dates the hour and minute
1024 is also omitted.
1025 --date=unix shows the date as a Unix epoch timestamp (seconds since
1027 1970). As with --raw, this is always in UTC and therefore -local
1028 has no effect.
1029 --date=format:... feeds the format ... to your system strftime,
1031 except for %z and %Z, which are handled internally. Use
1032 --date=format:%c to show the date in your system locale’s preferred
1033 format. See the strftime manual for a complete list of format
1034 placeholders. When using -local, the correct syntax is
1035 --date=format-local:....
1036 --date=default is the default format, and is similar to
1038 --date=rfc2822, with a few exceptions:
1039 • there is no comma after the day-of-week
1041 • the time zone is omitted when the local time zone is used
1043 --header
1045 Print the contents of the commit in raw-format; each record is
1046 separated with a NUL character.
1047 --parents
1049 Print also the parents of the commit (in the form "commit parent...
1050 "). Also enables parent rewriting, see History Simplification
1051 above.
1052 --children
1054 Print also the children of the commit (in the form "commit child...
1055 "). Also enables parent rewriting, see History Simplification
1056 above.
1057 --timestamp
1059 Print the raw commit timestamp.
1060 --left-right
1062 Mark which side of a symmetric difference a commit is reachable
1063 from. Commits from the left side are prefixed with < and those from
1064 the right with >. If combined with --boundary, those commits are
1065 prefixed with -.
1066 For example, if you have this topology:
1068 y---b---b branch B
1070 / \ /
1071 / .
1072 / / \
1073 o---x---a---a branch A
1074 you would get an output like this:
1076 $ git rev-list --left-right --boundary --pretty=oneline A...B
1078 >bbbbbbb... 3rd on b
1080 >bbbbbbb... 2nd on b
1081 <aaaaaaa... 3rd on a
1082 <aaaaaaa... 2nd on a
1083 -yyyyyyy... 1st on b
1084 -xxxxxxx... 1st on a
1085 --graph
1087 Draw a text-based graphical representation of the commit history on
1088 the left hand side of the output. This may cause extra lines to be
1089 printed in between commits, in order for the graph history to be
1090 drawn properly. Cannot be combined with --no-walk.
1091 This enables parent rewriting, see History Simplification above.
1093 This implies the --topo-order option by default, but the
1095 --date-order option may also be specified.
1096 --show-linear-break[=<barrier>]
1098 When --graph is not used, all history branches are flattened which
1099 can make it hard to see that the two consecutive commits do not
1100 belong to a linear branch. This option puts a barrier in between
1101 them in that case. If <barrier> is specified, it is the string that
1102 will be shown instead of the default one.
1103 --count
1105 Print a number stating how many commits would have been listed, and
1106 suppress all other output. When used together with --left-right,
1107 instead print the counts for left and right commits, separated by a
1108 tab. When used together with --cherry-mark, omit patch equivalent
1109 commits from these counts and print the count for equivalent
1110 commits separated by a tab.
1111
1113 If the commit is a merge, and if the pretty-format is not oneline,
1114 email or raw, an additional line is inserted before the Author: line.
1115 This line begins with "Merge: " and the hashes of ancestral commits are
1116 printed, separated by spaces. Note that the listed commits may not
1117 necessarily be the list of the direct parent commits if you have
1118 limited your view of history: for example, if you are only interested
1119 in changes related to a certain directory or file.
1120 There are several built-in formats, and you can define additional
1122 formats by setting a pretty.<name> config option to either another
1123 format name, or a format: string, as described below (see git-
1124 config(1)). Here are the details of the built-in formats:
1125 • oneline
1127 <hash> <title line>
1129 This is designed to be as compact as possible.
1131 • short
1133 commit <hash>
1135 Author: <author>
1136 <title line>
1138 • medium
1140 commit <hash>
1142 Author: <author>
1143 Date: <author date>
1144 <title line>
1146 <full commit message>
1148 • full
1150 commit <hash>
1152 Author: <author>
1153 Commit: <committer>
1154 <title line>
1156 <full commit message>
1158 • fuller
1160 commit <hash>
1162 Author: <author>
1163 AuthorDate: <author date>
1164 Commit: <committer>
1165 CommitDate: <committer date>
1166 <title line>
1168 <full commit message>
1170 • reference
1172 <abbrev hash> (<title line>, <short author date>)
1174 This format is used to refer to another commit in a commit message
1176 and is the same as --pretty='format:%C(auto)%h (%s, %ad)'. By
1177 default, the date is formatted with --date=short unless another
1178 --date option is explicitly specified. As with any format: with
1179 format placeholders, its output is not affected by other options
1180 like --decorate and --walk-reflogs.
1181 • email
1183 From <hash> <date>
1185 From: <author>
1186 Date: <author date>
1187 Subject: [PATCH] <title line>
1188 <full commit message>
1190 • mboxrd
1192 Like email, but lines in the commit message starting with "From "
1194 (preceded by zero or more ">") are quoted with ">" so they aren’t
1195 confused as starting a new commit.
1196 • raw
1198 The raw format shows the entire commit exactly as stored in the
1200 commit object. Notably, the hashes are displayed in full,
1201 regardless of whether --abbrev or --no-abbrev are used, and parents
1202 information show the true parent commits, without taking grafts or
1203 history simplification into account. Note that this format affects
1204 the way commits are displayed, but not the way the diff is shown
1205 e.g. with git log --raw. To get full object names in a raw diff
1206 format, use --no-abbrev.
1207 • format:<string>
1209 The format:<string> format allows you to specify which information
1211 you want to show. It works a little bit like printf format, with
1212 the notable exception that you get a newline with %n instead of \n.
1213 E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
1215 would show something like this:
1216 The author of fe6e0ee was Junio C Hamano, 23 hours ago
1218 The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
1219 The placeholders are:
1221 • Placeholders that expand to a single literal character:
1223 %n
1225 newline
1226 %%
1228 a raw %
1229 %x00
1231 print a byte from a hex code
1232 • Placeholders that affect formatting of later placeholders:
1234 %Cred
1236 switch color to red
1237 %Cgreen
1239 switch color to green
1240 %Cblue
1242 switch color to blue
1243 %Creset
1245 reset color
1246 %C(...)
1248 color specification, as described under Values in the
1249 "CONFIGURATION FILE" section of git-config(1). By default,
1250 colors are shown only when enabled for log output (by
1251 color.diff, color.ui, or --color, and respecting the auto
1252 settings of the former if we are going to a terminal).
1253 %C(auto,...) is accepted as a historical synonym for the
1254 default (e.g., %C(auto,red)). Specifying %C(always,...)
1255 will show the colors even when color is not otherwise
1256 enabled (though consider just using --color=always to
1257 enable color for the whole output, including this format
1258 and anything else git might color). auto alone (i.e.
1259 %C(auto)) will turn on auto coloring on the next
1260 placeholders until the color is switched again.
1261 %m
1263 left (<), right (>) or boundary (-) mark
1264 %w([<w>[,<i1>[,<i2>]]])
1266 switch line wrapping, like the -w option of git-
1267 shortlog(1).
1268 %<(<N>[,trunc|ltrunc|mtrunc])
1270 make the next placeholder take at least N columns, padding
1271 spaces on the right if necessary. Optionally truncate at
1272 the beginning (ltrunc), the middle (mtrunc) or the end
1273 (trunc) if the output is longer than N columns. Note that
1274 truncating only works correctly with N >= 2.
1275 %<|(<N>)
1277 make the next placeholder take at least until Nth columns,
1278 padding spaces on the right if necessary
1279 %>(<N>), %>|(<N>)
1281 similar to %<(<N>), %<|(<N>) respectively, but padding
1282 spaces on the left
1283 %>>(<N>), %>>|(<N>)
1285 similar to %>(<N>), %>|(<N>) respectively, except that if
1286 the next placeholder takes more spaces than given and there
1287 are spaces on its left, use those spaces
1288 %><(<N>), %><|(<N>)
1290 similar to %<(<N>), %<|(<N>) respectively, but padding both
1291 sides (i.e. the text is centered)
1292 • Placeholders that expand to information extracted from the
1294 commit:
1295 %H
1297 commit hash
1298 %h
1300 abbreviated commit hash
1301 %T
1303 tree hash
1304 %t
1306 abbreviated tree hash
1307 %P
1309 parent hashes
1310 %p
1312 abbreviated parent hashes
1313 %an
1315 author name
1316 %aN
1318 author name (respecting .mailmap, see git-shortlog(1) or
1319 git-blame(1))
1320 %ae
1322 author email
1323 %aE
1325 author email (respecting .mailmap, see git-shortlog(1) or
1326 git-blame(1))
1327 %al
1329 author email local-part (the part before the @ sign)
1330 %aL
1332 author local-part (see %al) respecting .mailmap, see git-
1333 shortlog(1) or git-blame(1))
1334 %ad
1336 author date (format respects --date= option)
1337 %aD
1339 author date, RFC2822 style
1340 %ar
1342 author date, relative
1343 %at
1345 author date, UNIX timestamp
1346 %ai
1348 author date, ISO 8601-like format
1349 %aI
1351 author date, strict ISO 8601 format
1352 %as
1354 author date, short format (YYYY-MM-DD)
1355 %cn
1357 committer name
1358 %cN
1360 committer name (respecting .mailmap, see git-shortlog(1) or
1361 git-blame(1))
1362 %ce
1364 committer email
1365 %cE
1367 committer email (respecting .mailmap, see git-shortlog(1)
1368 or git-blame(1))
1369 %cl
1371 committer email local-part (the part before the @ sign)
1372 %cL
1374 committer local-part (see %cl) respecting .mailmap, see
1375 git-shortlog(1) or git-blame(1))
1376 %cd
1378 committer date (format respects --date= option)
1379 %cD
1381 committer date, RFC2822 style
1382 %cr
1384 committer date, relative
1385 %ct
1387 committer date, UNIX timestamp
1388 %ci
1390 committer date, ISO 8601-like format
1391 %cI
1393 committer date, strict ISO 8601 format
1394 %cs
1396 committer date, short format (YYYY-MM-DD)
1397 %d
1399 ref names, like the --decorate option of git-log(1)
1400 %D
1402 ref names without the " (", ")" wrapping.
1403 %S
1405 ref name given on the command line by which the commit was
1406 reached (like git log --source), only works with git log
1407 %e
1409 encoding
1410 %s
1412 subject
1413 %f
1415 sanitized subject line, suitable for a filename
1416 %b
1418 body
1419 %B
1421 raw body (unwrapped subject and body)
1422 %GG
1424 raw verification message from GPG for a signed commit
1425 %G?
1427 show "G" for a good (valid) signature, "B" for a bad
1428 signature, "U" for a good signature with unknown validity,
1429 "X" for a good signature that has expired, "Y" for a good
1430 signature made by an expired key, "R" for a good signature
1431 made by a revoked key, "E" if the signature cannot be
1432 checked (e.g. missing key) and "N" for no signature
1433 %GS
1435 show the name of the signer for a signed commit
1436 %GK
1438 show the key used to sign a signed commit
1439 %GF
1441 show the fingerprint of the key used to sign a signed
1442 commit
1443 %GP
1445 show the fingerprint of the primary key whose subkey was
1446 used to sign a signed commit
1447 %GT
1449 show the trust level for the key used to sign a signed
1450 commit
1451 %gD
1453 reflog selector, e.g., refs/stash@{1} or refs/stash@{2
1454 minutes ago}; the format follows the rules described for
1455 the -g option. The portion before the @ is the refname as
1456 given on the command line (so git log -g refs/heads/master
1457 would yield refs/heads/master@{0}).
1458 %gd
1460 shortened reflog selector; same as %gD, but the refname
1461 portion is shortened for human readability (so
1462 refs/heads/master becomes just master).
1463 %gn
1465 reflog identity name
1466 %gN
1468 reflog identity name (respecting .mailmap, see git-
1469 shortlog(1) or git-blame(1))
1470 %ge
1472 reflog identity email
1473 %gE
1475 reflog identity email (respecting .mailmap, see git-
1476 shortlog(1) or git-blame(1))
1477 %gs
1479 reflog subject
1480 %(trailers[:options])
1482 display the trailers of the body as interpreted by git-
1483 interpret-trailers(1). The trailers string may be followed
1484 by a colon and zero or more comma-separated options. If any
1485 option is provided multiple times the last occurance wins.
1486 The boolean options accept an optional value [=<BOOL>]. The
1488 values true, false, on, off etc. are all accepted. See the
1489 "boolean" sub-section in "EXAMPLES" in git-config(1). If a
1490 boolean option is given with no value, it’s enabled.
1491 • key=<K>: only show trailers with specified key.
1493 Matching is done case-insensitively and trailing colon
1494 is optional. If option is given multiple times trailer
1495 lines matching any of the keys are shown. This option
1496 automatically enables the only option so that
1497 non-trailer lines in the trailer block are hidden. If
1498 that is not desired it can be disabled with only=false.
1499 E.g., %(trailers:key=Reviewed-by) shows trailer lines
1500 with key Reviewed-by.
1501 • only[=<BOOL>]: select whether non-trailer lines from
1503 the trailer block should be included.
1504 • separator=<SEP>: specify a separator inserted between
1506 trailer lines. When this option is not given each
1507 trailer line is terminated with a line feed character.
1508 The string SEP may contain the literal formatting codes
1509 described above. To use comma as separator one must use
1510 %x2C as it would otherwise be parsed as next option.
1511 E.g., %(trailers:key=Ticket,separator=%x2C ) shows all
1512 trailer lines whose key is "Ticket" separated by a
1513 comma and a space.
1514 • unfold[=<BOOL>]: make it behave as if
1516 interpret-trailer’s --unfold option was given. E.g.,
1517 %(trailers:only,unfold=true) unfolds and shows all
1518 trailer lines.
1519 • keyonly[=<BOOL>]: only show the key part of the
1521 trailer.
1522 • valueonly[=<BOOL>]: only show the value part of the
1524 trailer.
1525 • key_value_separator=<SEP>: specify a separator inserted
1527 between trailer lines. When this option is not given
1528 each trailer key-value pair is separated by ": ".
1529 Otherwise it shares the same semantics as
1530 separator=<SEP> above.
1531 Note
1533 Some placeholders may depend on other options given to the revision
1534 traversal engine. For example, the %g* reflog options will insert
1535 an empty string unless we are traversing reflog entries (e.g., by
1536 git log -g). The %d and %D placeholders will use the "short"
1537 decoration format if --decorate was not already provided on the
1538 command line.
1539 If you add a + (plus sign) after % of a placeholder, a line-feed is
1541 inserted immediately before the expansion if and only if the
1542 placeholder expands to a non-empty string.
1543 If you add a - (minus sign) after % of a placeholder, all consecutive
1545 line-feeds immediately preceding the expansion are deleted if and only
1546 if the placeholder expands to an empty string.
1547 If you add a ` ` (space) after % of a placeholder, a space is inserted
1549 immediately before the expansion if and only if the placeholder expands
1550 to a non-empty string.
1551 • tformat:
1553 The tformat: format works exactly like format:, except that it
1555 provides "terminator" semantics instead of "separator" semantics.
1556 In other words, each commit has the message terminator character
1557 (usually a newline) appended, rather than a separator placed
1558 between entries. This means that the final entry of a single-line
1559 format will be properly terminated with a new line, just as the
1560 "oneline" format does. For example:
1561 $ git log -2 --pretty=format:%h 4da45bef \
1563 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
1564 4da45be
1565 7134973 -- NO NEWLINE
1566 $ git log -2 --pretty=tformat:%h 4da45bef \
1568 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
1569 4da45be
1570 7134973
1571 In addition, any unrecognized string that has a % in it is
1573 interpreted as if it has tformat: in front of it. For example,
1574 these two are equivalent:
1575 $ git log -2 --pretty=tformat:%h 4da45bef
1577 $ git log -2 --pretty=%h 4da45bef
1578
1580 • Print the list of commits reachable from the current branch.
1581 git rev-list HEAD
1583 • Print the list of commits on this branch, but not present in the
1585 upstream branch.
1586 git rev-list @{upstream}..HEAD
1588 • Format commits with their author and commit message (see also the
1590 porcelain git-log(1)).
1591 git rev-list --format=medium HEAD
1593 • Format commits along with their diffs (see also the porcelain git-
1595 log(1), which can do this in a single process).
1596 git rev-list HEAD |
1598 git diff-tree --stdin --format=medium -p
1599 • Print the list of commits on the current branch that touched any
1601 file in the Documentation directory.
1602 git rev-list HEAD -- Documentation/
1604 • Print the list of commits authored by you in the past year, on any
1606 branch, tag, or other ref.
1607 git rev-list --author=you@example.com --since=1.year.ago --all
1609 • Print the list of objects reachable from the current branch (i.e.,
1611 all commits and the blobs and trees they contain).
1612 git rev-list --objects HEAD
1614 • Compare the disk size of all reachable objects, versus those
1616 reachable from reflogs, versus the total packed size. This can tell
1617 you whether running git repack -ad might reduce the repository size
1618 (by dropping unreachable objects), and whether expiring reflogs
1619 might help.
1620 # reachable objects
1622 git rev-list --disk-usage --objects --all
1623 # plus reflogs
1624 git rev-list --disk-usage --objects --all --reflog
1625 # total disk size used
1626 du -c .git/objects/pack/*.pack .git/objects/??/*
1627 # alternative to du: add up "size" and "size-pack" fields
1628 git count-objects -v
1629 • Report the disk size of each branch, not including objects used by
1631 the current branch. This can find outliers that are contributing to
1632 a bloated repository size (e.g., because somebody accidentally
1633 committed large build artifacts).
1634 git for-each-ref --format='%(refname)' |
1636 while read branch
1637 do
1638 size=$(git rev-list --disk-usage --objects HEAD..$branch)
1639 echo "$size $branch"
1640 done |
1641 sort -n
1642 • Compare the on-disk size of branches in one group of refs,
1644 excluding another. If you co-mingle objects from multiple remotes
1645 in a single repository, this can show which remotes are
1646 contributing to the repository size (taking the size of origin as a
1647 baseline).
1648 git rev-list --disk-usage --objects --remotes=$suspect --not --remotes=origin
1650
1652 Part of the git(1) suite
1653Git 2.31.1 2021-03-26 GIT-REV-LIST(1)