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 [ --max-count=<number> ]
10 [ --skip=<number> ]
11 [ --max-age=<timestamp> ]
12 [ --min-age=<timestamp> ]
13 [ --sparse ]
14 [ --merges ]
15 [ --no-merges ]
16 [ --min-parents=<number> ]
17 [ --no-min-parents ]
18 [ --max-parents=<number> ]
19 [ --no-max-parents ]
20 [ --first-parent ]
21 [ --remove-empty ]
22 [ --full-history ]
23 [ --not ]
24 [ --all ]
25 [ --branches[=<pattern>] ]
26 [ --tags[=<pattern>] ]
27 [ --remotes[=<pattern>] ]
28 [ --glob=<glob-pattern> ]
29 [ --ignore-missing ]
30 [ --stdin ]
31 [ --quiet ]
32 [ --topo-order ]
33 [ --parents ]
34 [ --timestamp ]
35 [ --left-right ]
36 [ --left-only ]
37 [ --right-only ]
38 [ --cherry-mark ]
39 [ --cherry-pick ]
40 [ --encoding[=<encoding>] ]
41 [ --(author|committer|grep)=<pattern> ]
42 [ --regexp-ignore-case | -i ]
43 [ --extended-regexp | -E ]
44 [ --fixed-strings | -F ]
45 [ --date=(local|relative|default|iso|rfc|short) ]
46 [ [--objects | --objects-edge] [ --unpacked ] ]
47 [ --pretty | --header ]
48 [ --bisect ]
49 [ --bisect-vars ]
50 [ --bisect-all ]
51 [ --merge ]
52 [ --reverse ]
53 [ --walk-reflogs ]
54 [ --no-walk ] [ --do-walk ]
55 <commit>... [ -- <paths>... ]
56
59 List commits that are reachable by following the parent links from the
60 given commit(s), but exclude commits that are reachable from the one(s)
61 given with a ^ in front of them. The output is given in reverse
62 chronological order by default.
63 You can think of this as a set operation. Commits given on the command
65 line form a set of commits that are reachable from any of them, and
66 then commits reachable from any of the ones given with ^ in front are
67 subtracted from that set. The remaining commits are what comes out in
68 the command’s output. Various other options and paths parameters can be
69 used to further limit the result.
70 Thus, the following command:
72 $ git rev-list foo bar ^baz
74 means "list all the commits which are reachable from foo or bar, but
77 not from baz".
78 A special notation "<commit1>..<commit2>" can be used as a short-hand
80 for "^'<commit1>' <commit2>". For example, either of the following may
81 be used interchangeably:
82 $ git rev-list origin..HEAD
84 $ git rev-list HEAD ^origin
85 Another special notation is "<commit1>...<commit2>" which is useful for
88 merges. The resulting set of commits is the symmetric difference
89 between the two operands. The following two commands are equivalent:
90 $ git rev-list A B --not $(git merge-base --all A B)
92 $ git rev-list A...B
93 rev-list is a very essential Git command, since it provides the ability
96 to build and traverse commit ancestry graphs. For this reason, it has a
97 lot of different options that enables it to be used by commands as
98 different as git bisect and git repack.
99
101 Commit Limiting
102 Besides specifying a range of commits that should be listed using the
103 special notations explained in the description, additional commit
104 limiting may be applied.
105 Using more options generally further limits the output (e.g.
107 --since=<date1> limits to commits newer than <date1>, and using it with
108 --grep=<pattern> further limits to commits whose log message has a line
109 that matches <pattern>), unless otherwise noted.
110 Note that these are applied before commit ordering and formatting
112 options, such as --reverse.
113 -<number>, -n <number>, --max-count=<number>
115 Limit the number of commits to output.
116 --skip=<number>
118 Skip number commits before starting to show the commit output.
119 --since=<date>, --after=<date>
121 Show commits more recent than a specific date.
122 --until=<date>, --before=<date>
124 Show commits older than a specific date.
125 --max-age=<timestamp>, --min-age=<timestamp>
127 Limit the commits output to specified time range.
128 --author=<pattern>, --committer=<pattern>
130 Limit the commits output to ones with author/committer header lines
131 that match the specified pattern (regular expression). With more
132 than one --author=<pattern>, commits whose author matches any of
133 the given patterns are chosen (similarly for multiple
134 --committer=<pattern>).
135 --grep-reflog=<pattern>
137 Limit the commits output to ones with reflog entries that match the
138 specified pattern (regular expression). With more than one
139 --grep-reflog, commits whose reflog message matches any of the
140 given patterns are chosen. It is an error to use this option unless
141 --walk-reflogs is in use.
142 --grep=<pattern>
144 Limit the commits output to ones with log message that matches the
145 specified pattern (regular expression). With more than one
146 --grep=<pattern>, commits whose message matches any of the given
147 patterns are chosen (but see --all-match).
148 When --show-notes is in effect, the message from the notes as if it
150 is part of the log message.
151 --all-match
153 Limit the commits output to ones that match all given --grep,
154 instead of ones that match at least one.
155 -i, --regexp-ignore-case
157 Match the regexp limiting patterns without regard to letters case.
158 --basic-regexp
160 Consider the limiting patterns to be basic regular expressions;
161 this is the default.
162 -E, --extended-regexp
164 Consider the limiting patterns to be extended regular expressions
165 instead of the default basic regular expressions.
166 -F, --fixed-strings
168 Consider the limiting patterns to be fixed strings (don’t interpret
169 pattern as a regular expression).
170 --perl-regexp
172 Consider the limiting patterns to be Perl-compatible regexp.
173 Requires libpcre to be compiled in.
174 --remove-empty
176 Stop when a given path disappears from the tree.
177 --merges
179 Print only merge commits. This is exactly the same as
180 --min-parents=2.
181 --no-merges
183 Do not print commits with more than one parent. This is exactly the
184 same as --max-parents=1.
185 --min-parents=<number>, --max-parents=<number>, --no-min-parents,
187 --no-max-parents
188 Show only commits which have at least (or at most) that many
189 commits. In particular, --max-parents=1 is the same as --no-merges,
190 --min-parents=2 is the same as --merges. --max-parents=0 gives all
191 root commits and --min-parents=3 all octopus merges.
192 --no-min-parents and --no-max-parents reset these limits (to no
194 limit) again. Equivalent forms are --min-parents=0 (any commit has
195 0 or more parents) and --max-parents=-1 (negative numbers denote no
196 upper limit).
197 --first-parent
199 Follow only the first parent commit upon seeing a merge commit.
200 This option can give a better overview when viewing the evolution
201 of a particular topic branch, because merges into a topic branch
202 tend to be only about adjusting to updated upstream from time to
203 time, and this option allows you to ignore the individual commits
204 brought in to your history by such a merge.
205 --not
207 Reverses the meaning of the ^ prefix (or lack thereof) for all
208 following revision specifiers, up to the next --not.
209 --all
211 Pretend as if all the refs in refs/ are listed on the command line
212 as <commit>.
213 --branches[=<pattern>]
215 Pretend as if all the refs in refs/heads are listed on the command
216 line as <commit>. If <pattern> is given, limit branches to ones
217 matching given shell glob. If pattern lacks ?, *, or [, /* at the
218 end is implied.
219 --tags[=<pattern>]
221 Pretend as if all the refs in refs/tags are listed on the command
222 line as <commit>. If <pattern> is given, limit tags to ones
223 matching given shell glob. If pattern lacks ?, *, or [, /* at the
224 end is implied.
225 --remotes[=<pattern>]
227 Pretend as if all the refs in refs/remotes are listed on the
228 command line as <commit>. If <pattern> is given, limit
229 remote-tracking branches to ones matching given shell glob. If
230 pattern lacks ?, *, or [, /* at the end is implied.
231 --glob=<glob-pattern>
233 Pretend as if all the refs matching shell glob <glob-pattern> are
234 listed on the command line as <commit>. Leading refs/, is
235 automatically prepended if missing. If pattern lacks ?, *, or [, /*
236 at the end is implied.
237 --ignore-missing
239 Upon seeing an invalid object name in the input, pretend as if the
240 bad input was not given.
241 --stdin
243 In addition to the <commit> listed on the command line, read them
244 from the standard input. If a -- separator is seen, stop reading
245 commits and start reading paths to limit the result.
246 --quiet
248 Don’t print anything to standard output. This form is primarily
249 meant to allow the caller to test the exit status to see if a range
250 of objects is fully connected (or not). It is faster than
251 redirecting stdout to /dev/null as the output does not have to be
252 formatted.
253 --cherry-mark
255 Like --cherry-pick (see below) but mark equivalent commits with =
256 rather than omitting them, and inequivalent ones with +.
257 --cherry-pick
259 Omit any commit that introduces the same change as another commit
260 on the "other side" when the set of commits are limited with
261 symmetric difference.
262 For example, if you have two branches, A and B, a usual way to list
264 all commits on only one side of them is with --left-right (see the
265 example below in the description of the --left-right option). It
266 however shows the commits that were cherry-picked from the other
267 branch (for example, "3rd on b" may be cherry-picked from branch
268 A). With this option, such pairs of commits are excluded from the
269 output.
270 --left-only, --right-only
272 List only commits on the respective side of a symmetric range, i.e.
273 only those which would be marked < resp. > by --left-right.
274 For example, --cherry-pick --right-only A...B omits those commits
276 from B which are in A or are patch-equivalent to a commit in A. In
277 other words, this lists the + commits from git cherry A B. More
278 precisely, --cherry-pick --right-only --no-merges gives the exact
279 list.
280 --cherry
282 A synonym for --right-only --cherry-mark --no-merges; useful to
283 limit the output to the commits on our side and mark those that
284 have been applied to the other side of a forked history with git
285 log --cherry upstream...mybranch, similar to git cherry upstream
286 mybranch.
287 -g, --walk-reflogs
289 Instead of walking the commit ancestry chain, walk reflog entries
290 from the most recent one to older ones. When this option is used
291 you cannot specify commits to exclude (that is, ^commit,
292 commit1..commit2, nor commit1...commit2 notations cannot be used).
293 With --pretty format other than oneline (for obvious reasons), this
295 causes the output to have two extra lines of information taken from
296 the reflog. By default, commit@{Nth} notation is used in the
297 output. When the starting commit is specified as commit@{now},
298 output also uses commit@{timestamp} notation instead. Under
299 --pretty=oneline, the commit message is prefixed with this
300 information on the same line. This option cannot be combined with
301 --reverse. See also git-reflog(1).
302 --merge
304 After a failed merge, show refs that touch files having a conflict
305 and don’t exist on all heads to merge.
306 --boundary
308 Output uninteresting commits at the boundary, which are usually not
309 shown.
310 History Simplification
312 Sometimes you are only interested in parts of the history, for example
313 the commits modifying a particular <path>. But there are two parts of
314 History Simplification, one part is selecting the commits and the other
315 is how to do it, as there are various strategies to simplify the
316 history.
317 The following options select the commits to be shown:
319 <paths>
321 Commits modifying the given <paths> are selected.
322 --simplify-by-decoration
324 Commits that are referred by some branch or tag are selected.
325 Note that extra commits can be shown to give a meaningful history.
327 The following options affect the way the simplification is performed:
329 Default mode
331 Simplifies the history to the simplest history explaining the final
332 state of the tree. Simplest because it prunes some side branches if
333 the end result is the same (i.e. merging branches with the same
334 content)
335 --full-history
337 Same as the default mode, but does not prune some history.
338 --dense
340 Only the selected commits are shown, plus some to have a meaningful
341 history.
342 --sparse
344 All commits in the simplified history are shown.
345 --simplify-merges
347 Additional option to --full-history to remove some needless merges
348 from the resulting history, as there are no selected commits
349 contributing to this merge.
350 --ancestry-path
352 When given a range of commits to display (e.g. commit1..commit2 or
353 commit2 ^commit1), only display commits that exist directly on the
354 ancestry chain between the commit1 and commit2, i.e. commits that
355 are both descendants of commit1, and ancestors of commit2.
356 A more detailed explanation follows.
358 Suppose you specified foo as the <paths>. We shall call commits that
360 modify foo !TREESAME, and the rest TREESAME. (In a diff filtered for
361 foo, they look different and equal, respectively.)
362 In the following, we will always refer to the same example history to
364 illustrate the differences between simplification settings. We assume
365 that you are filtering for a file foo in this commit graph:
366 .-A---M---N---O---P
368 / / / / /
369 I B C D E
370 \ / / / /
371 `-------------'
372 The horizontal line of history A---P is taken to be the first parent of
375 each merge. The commits are:
376 · I is the initial commit, in which foo exists with contents "asdf",
378 and a file quux exists with contents "quux". Initial commits are
379 compared to an empty tree, so I is !TREESAME.
380 · In A, foo contains just "foo".
382 · B contains the same change as A. Its merge M is trivial and hence
384 TREESAME to all parents.
385 · C does not change foo, but its merge N changes it to "foobar", so
387 it is not TREESAME to any parent.
388 · D sets foo to "baz". Its merge O combines the strings from N and D
390 to "foobarbaz"; i.e., it is not TREESAME to any parent.
391 · E changes quux to "xyzzy", and its merge P combines the strings to
393 "quux xyzzy". Despite appearing interesting, P is TREESAME to all
394 parents.
395 rev-list walks backwards through history, including or excluding
397 commits based on whether --full-history and/or parent rewriting (via
398 --parents or --children) are used. The following settings are
399 available.
400 Default mode
402 Commits are included if they are not TREESAME to any parent (though
403 this can be changed, see --sparse below). If the commit was a
404 merge, and it was TREESAME to one parent, follow only that parent.
405 (Even if there are several TREESAME parents, follow only one of
406 them.) Otherwise, follow all parents.
407 This results in:
409 .-A---N---O
411 / / /
412 I---------D
413 Note how the rule to only follow the TREESAME parent, if one is
415 available, removed B from consideration entirely. C was considered
416 via N, but is TREESAME. Root commits are compared to an empty tree,
417 so I is !TREESAME.
418 Parent/child relations are only visible with --parents, but that
420 does not affect the commits selected in default mode, so we have
421 shown the parent lines.
422 --full-history without parent rewriting
424 This mode differs from the default in one point: always follow all
425 parents of a merge, even if it is TREESAME to one of them. Even if
426 more than one side of the merge has commits that are included, this
427 does not imply that the merge itself is! In the example, we get
428 I A B N D O
430 P and M were excluded because they are TREESAME to a parent. E, C
432 and B were all walked, but only B was !TREESAME, so the others do
433 not appear.
434 Note that without parent rewriting, it is not really possible to
436 talk about the parent/child relationships between the commits, so
437 we show them disconnected.
438 --full-history with parent rewriting
440 Ordinary commits are only included if they are !TREESAME (though
441 this can be changed, see --sparse below).
442 Merges are always included. However, their parent list is
444 rewritten: Along each parent, prune away commits that are not
445 included themselves. This results in
446 .-A---M---N---O---P
448 / / / / /
449 I B / D /
450 \ / / / /
451 `-------------'
452 Compare to --full-history without rewriting above. Note that E was
454 pruned away because it is TREESAME, but the parent list of P was
455 rewritten to contain E's parent I. The same happened for C and N.
456 Note also that P was included despite being TREESAME.
457 In addition to the above settings, you can change whether TREESAME
459 affects inclusion:
460 --dense
462 Commits that are walked are included if they are not TREESAME to
463 any parent.
464 --sparse
466 All commits that are walked are included.
467 Note that without --full-history, this still simplifies merges: if
469 one of the parents is TREESAME, we follow only that one, so the
470 other sides of the merge are never walked.
471 --simplify-merges
473 First, build a history graph in the same way that --full-history
474 with parent rewriting does (see above).
475 Then simplify each commit C to its replacement C' in the final
477 history according to the following rules:
478 · Set C' to C.
480 · Replace each parent P of C' with its simplification P'. In the
482 process, drop parents that are ancestors of other parents, and
483 remove duplicates.
484 · If after this parent rewriting, C' is a root or merge commit
486 (has zero or >1 parents), a boundary commit, or !TREESAME, it
487 remains. Otherwise, it is replaced with its only parent.
488 The effect of this is best shown by way of comparing to
490 --full-history with parent rewriting. The example turns into:
491 .-A---M---N---O
493 / / /
494 I B D
495 \ / /
496 `---------'
497 Note the major differences in N and P over --full-history:
499 · N's parent list had I removed, because it is an ancestor of the
501 other parent M. Still, N remained because it is !TREESAME.
502 · P's parent list similarly had I removed. P was then removed
504 completely, because it had one parent and is TREESAME.
505 Finally, there is a fifth simplification mode available:
507 --ancestry-path
509 Limit the displayed commits to those directly on the ancestry chain
510 between the "from" and "to" commits in the given commit range. I.e.
511 only display commits that are ancestor of the "to" commit, and
512 descendants of the "from" commit.
513 As an example use case, consider the following commit history:
515 D---E-------F
517 / \ \
518 B---C---G---H---I---J
519 / \
520 A-------K---------------L--M
521 A regular D..M computes the set of commits that are ancestors of M,
523 but excludes the ones that are ancestors of D. This is useful to
524 see what happened to the history leading to M since D, in the sense
525 that "what does M have that did not exist in D". The result in this
526 example would be all the commits, except A and B (and D itself, of
527 course).
528 When we want to find out what commits in M are contaminated with
530 the bug introduced by D and need fixing, however, we might want to
531 view only the subset of D..M that are actually descendants of D,
532 i.e. excluding C and K. This is exactly what the --ancestry-path
533 option does. Applied to the D..M range, it results in:
534 E-------F
536 \ \
537 G---H---I---J
538 \
539 L--M
540 The --simplify-by-decoration option allows you to view only the big
543 picture of the topology of the history, by omitting commits that are
544 not referenced by tags. Commits are marked as !TREESAME (in other
545 words, kept after history simplification rules described above) if (1)
546 they are referenced by tags, or (2) they change the contents of the
547 paths given on the command line. All other commits are marked as
548 TREESAME (subject to be simplified away).
549 Bisection Helpers
551 --bisect
552 Limit output to the one commit object which is roughly halfway
553 between included and excluded commits. Note that the bad bisection
554 ref refs/bisect/bad is added to the included commits (if it exists)
555 and the good bisection refs refs/bisect/good-* are added to the
556 excluded commits (if they exist). Thus, supposing there are no refs
557 in refs/bisect/, if
558 $ git rev-list --bisect foo ^bar ^baz
560 outputs midpoint, the output of the two commands
563 $ git rev-list foo ^midpoint
565 $ git rev-list midpoint ^bar ^baz
566 would be of roughly the same length. Finding the change which
569 introduces a regression is thus reduced to a binary search: repeatedly
570 generate and test new 'midpoint’s until the commit chain is of length
571 one.
572 --bisect-vars
574 This calculates the same as --bisect, except that refs in
575 refs/bisect/ are not used, and except that this outputs text ready
576 to be eval’ed by the shell. These lines will assign the name of the
577 midpoint revision to the variable bisect_rev, and the expected
578 number of commits to be tested after bisect_rev is tested to
579 bisect_nr, the expected number of commits to be tested if
580 bisect_rev turns out to be good to bisect_good, the expected number
581 of commits to be tested if bisect_rev turns out to be bad to
582 bisect_bad, and the number of commits we are bisecting right now to
583 bisect_all.
584 --bisect-all
586 This outputs all the commit objects between the included and
587 excluded commits, ordered by their distance to the included and
588 excluded commits. Refs in refs/bisect/ are not used. The farthest
589 from them is displayed first. (This is the only one displayed by
590 --bisect.)
591 This is useful because it makes it easy to choose a good commit to
593 test when you want to avoid to test some of them for some reason
594 (they may not compile for example).
595 This option can be used along with --bisect-vars, in this case,
597 after all the sorted commit objects, there will be the same text as
598 if --bisect-vars had been used alone.
599 Commit Ordering
601 By default, the commits are shown in reverse chronological order.
602 --date-order
604 Show no parents before all of its children are shown, but otherwise
605 show commits in the commit timestamp order.
606 --topo-order
608 Show no parents before all of its children are shown, and avoid
609 showing commits on multiple lines of history intermixed.
610 For example, in a commit history like this:
612 ---1----2----4----7
614 \ \
615 3----5----6----8---
616 where the numbers denote the order of commit timestamps, git
618 rev-list and friends with --date-order show the commits in the
619 timestamp order: 8 7 6 5 4 3 2 1.
620 With --topo-order, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5
622 3 1); some older commits are shown before newer ones in order to
623 avoid showing the commits from two parallel development track mixed
624 together.
625 --reverse
627 Output the commits in reverse order. Cannot be combined with
628 --walk-reflogs.
629 Object Traversal
631 These options are mostly targeted for packing of Git repositories.
632 --objects
634 Print the object IDs of any object referenced by the listed
635 commits. --objects foo ^bar thus means "send me all object IDs
636 which I need to download if I have the commit object bar, but not
637 foo".
638 --objects-edge
640 Similar to --objects, but also print the IDs of excluded commits
641 prefixed with a "-" character. This is used by git-pack-objects(1)
642 to build "thin" pack, which records objects in deltified form based
643 on objects contained in these excluded commits to reduce network
644 traffic.
645 --unpacked
647 Only useful with --objects; print the object IDs that are not in
648 packs.
649 --no-walk[=(sorted|unsorted)]
651 Only show the given commits, but do not traverse their ancestors.
652 This has no effect if a range is specified. If the argument
653 "unsorted" is given, the commits are show in the order they were
654 given on the command line. Otherwise (if "sorted" or no argument
655 was given), the commits are show in reverse chronological order by
656 commit time.
657 --do-walk
659 Overrides a previous --no-walk.
660 Commit Formatting
662 Using these options, git-rev-list(1) will act similar to the more
663 specialized family of commit log tools: git-log(1), git-show(1), and
664 git-whatchanged(1)
665 --pretty[=<format>], --format=<format>
667 Pretty-print the contents of the commit logs in a given format,
668 where <format> can be one of oneline, short, medium, full, fuller,
669 email, raw and format:<string>. See the "PRETTY FORMATS" section
670 for some additional details for each format. When omitted, the
671 format defaults to medium.
672 Note: you can specify the default pretty format in the repository
674 configuration (see git-config(1)).
675 --abbrev-commit
677 Instead of showing the full 40-byte hexadecimal commit object name,
678 show only a partial prefix. Non default number of digits can be
679 specified with "--abbrev=<n>" (which also modifies diff output, if
680 it is displayed).
681 This should make "--pretty=oneline" a whole lot more readable for
683 people using 80-column terminals.
684 --no-abbrev-commit
686 Show the full 40-byte hexadecimal commit object name. This negates
687 --abbrev-commit and those options which imply it such as
688 "--oneline". It also overrides the log.abbrevCommit variable.
689 --oneline
691 This is a shorthand for "--pretty=oneline --abbrev-commit" used
692 together.
693 --encoding[=<encoding>]
695 The commit objects record the encoding used for the log message in
696 their encoding header; this option can be used to tell the command
697 to re-code the commit log message in the encoding preferred by the
698 user. For non plumbing commands this defaults to UTF-8.
699 --notes[=<ref>]
701 Show the notes (see git-notes(1)) that annotate the commit, when
702 showing the commit log message. This is the default for git log,
703 git show and git whatchanged commands when there is no --pretty,
704 --format nor --oneline option given on the command line.
705 By default, the notes shown are from the notes refs listed in the
707 core.notesRef and notes.displayRef variables (or corresponding
708 environment overrides). See git-config(1) for more details.
709 With an optional <ref> argument, show this notes ref instead of the
711 default notes ref(s). The ref is taken to be in refs/notes/ if it
712 is not qualified.
713 Multiple --notes options can be combined to control which notes are
715 being displayed. Examples: "--notes=foo" will show only notes from
716 "refs/notes/foo"; "--notes=foo --notes" will show both notes from
717 "refs/notes/foo" and from the default notes ref(s).
718 --no-notes
720 Do not show notes. This negates the above --notes option, by
721 resetting the list of notes refs from which notes are shown.
722 Options are parsed in the order given on the command line, so e.g.
723 "--notes --notes=foo --no-notes --notes=bar" will only show notes
724 from "refs/notes/bar".
725 --show-notes[=<ref>], --[no-]standard-notes
727 These options are deprecated. Use the above --notes/--no-notes
728 options instead.
729 --show-signature
731 Check the validity of a signed commit object by passing the
732 signature to gpg --verify and show the output.
733 --relative-date
735 Synonym for --date=relative.
736 --date=(relative|local|default|iso|rfc|short|raw)
738 Only takes effect for dates shown in human-readable format, such as
739 when using "--pretty". log.date config variable sets a default
740 value for log command’s --date option.
741 --date=relative shows dates relative to the current time, e.g. "2
743 hours ago".
744 --date=local shows timestamps in user’s local timezone.
746 --date=iso (or --date=iso8601) shows timestamps in ISO 8601 format.
748 --date=rfc (or --date=rfc2822) shows timestamps in RFC 2822 format,
750 often found in E-mail messages.
751 --date=short shows only date but not time, in YYYY-MM-DD format.
753 --date=raw shows the date in the internal raw Git format %s %z
755 format.
756 --date=default shows timestamps in the original timezone (either
758 committer’s or author’s).
759 --header
761 Print the contents of the commit in raw-format; each record is
762 separated with a NUL character.
763 --parents
765 Print also the parents of the commit (in the form "commit
766 parent..."). Also enables parent rewriting, see History
767 Simplification below.
768 --children
770 Print also the children of the commit (in the form "commit
771 child..."). Also enables parent rewriting, see History
772 Simplification below.
773 --timestamp
775 Print the raw commit timestamp.
776 --left-right
778 Mark which side of a symmetric diff a commit is reachable from.
779 Commits from the left side are prefixed with < and those from the
780 right with >. If combined with --boundary, those commits are
781 prefixed with -.
782 For example, if you have this topology:
784 y---b---b branch B
786 / \ /
787 / .
788 / / \
789 o---x---a---a branch A
790 you would get an output like this:
792 $ git rev-list --left-right --boundary --pretty=oneline A...B
794 >bbbbbbb... 3rd on b
796 >bbbbbbb... 2nd on b
797 <aaaaaaa... 3rd on a
798 <aaaaaaa... 2nd on a
799 -yyyyyyy... 1st on b
800 -xxxxxxx... 1st on a
801 --graph
804 Draw a text-based graphical representation of the commit history on
805 the left hand side of the output. This may cause extra lines to be
806 printed in between commits, in order for the graph history to be
807 drawn properly.
808 This enables parent rewriting, see History Simplification below.
810 This implies the --topo-order option by default, but the
812 --date-order option may also be specified.
813 --count
815 Print a number stating how many commits would have been listed, and
816 suppress all other output. When used together with --left-right,
817 instead print the counts for left and right commits, separated by a
818 tab. When used together with --cherry-mark, omit patch equivalent
819 commits from these counts and print the count for equivalent
820 commits separated by a tab.
821
823 If the commit is a merge, and if the pretty-format is not oneline,
824 email or raw, an additional line is inserted before the Author: line.
825 This line begins with "Merge: " and the sha1s of ancestral commits are
826 printed, separated by spaces. Note that the listed commits may not
827 necessarily be the list of the direct parent commits if you have
828 limited your view of history: for example, if you are only interested
829 in changes related to a certain directory or file.
830 There are several built-in formats, and you can define additional
832 formats by setting a pretty.<name> config option to either another
833 format name, or a format: string, as described below (see git-
834 config(1)). Here are the details of the built-in formats:
835 · oneline
837 <sha1> <title line>
839 This is designed to be as compact as possible.
841 · short
843 commit <sha1>
845 Author: <author>
846 <title line>
848 · medium
850 commit <sha1>
852 Author: <author>
853 Date: <author date>
854 <title line>
856 <full commit message>
858 · full
860 commit <sha1>
862 Author: <author>
863 Commit: <committer>
864 <title line>
866 <full commit message>
868 · fuller
870 commit <sha1>
872 Author: <author>
873 AuthorDate: <author date>
874 Commit: <committer>
875 CommitDate: <committer date>
876 <title line>
878 <full commit message>
880 · email
882 From <sha1> <date>
884 From: <author>
885 Date: <author date>
886 Subject: [PATCH] <title line>
887 <full commit message>
889 · raw
891 The raw format shows the entire commit exactly as stored in the
893 commit object. Notably, the SHA-1s are displayed in full,
894 regardless of whether --abbrev or --no-abbrev are used, and parents
895 information show the true parent commits, without taking grafts nor
896 history simplification into account.
897 · format:<string>
899 The format:<string> format allows you to specify which information
901 you want to show. It works a little bit like printf format, with
902 the notable exception that you get a newline with %n instead of \n.
903 E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
905 would show something like this:
906 The author of fe6e0ee was Junio C Hamano, 23 hours ago
908 The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
909 The placeholders are:
911 · %H: commit hash
913 · %h: abbreviated commit hash
915 · %T: tree hash
917 · %t: abbreviated tree hash
919 · %P: parent hashes
921 · %p: abbreviated parent hashes
923 · %an: author name
925 · %aN: author name (respecting .mailmap, see git-shortlog(1) or
927 git-blame(1))
928 · %ae: author email
930 · %aE: author email (respecting .mailmap, see git-shortlog(1) or
932 git-blame(1))
933 · %ad: author date (format respects --date= option)
935 · %aD: author date, RFC2822 style
937 · %ar: author date, relative
939 · %at: author date, UNIX timestamp
941 · %ai: author date, ISO 8601 format
943 · %cn: committer name
945 · %cN: committer name (respecting .mailmap, see git-shortlog(1)
947 or git-blame(1))
948 · %ce: committer email
950 · %cE: committer email (respecting .mailmap, see git-shortlog(1)
952 or git-blame(1))
953 · %cd: committer date
955 · %cD: committer date, RFC2822 style
957 · %cr: committer date, relative
959 · %ct: committer date, UNIX timestamp
961 · %ci: committer date, ISO 8601 format
963 · %d: ref names, like the --decorate option of git-log(1)
965 · %e: encoding
967 · %s: subject
969 · %f: sanitized subject line, suitable for a filename
971 · %b: body
973 · %B: raw body (unwrapped subject and body)
975 · %N: commit notes
977 · %GG: raw verification message from GPG for a signed commit
979 · %G?: show "G" for a Good signature, "B" for a Bad signature,
981 "U" for a good, untrusted signature and "N" for no signature
982 · %GS: show the name of the signer for a signed commit
984 · %GK: show the key used to sign a signed commit
986 · %gD: reflog selector, e.g., refs/stash@{1}
988 · %gd: shortened reflog selector, e.g., stash@{1}
990 · %gn: reflog identity name
992 · %gN: reflog identity name (respecting .mailmap, see git-
994 shortlog(1) or git-blame(1))
995 · %ge: reflog identity email
997 · %gE: reflog identity email (respecting .mailmap, see git-
999 shortlog(1) or git-blame(1))
1000 · %gs: reflog subject
1002 · %Cred: switch color to red
1004 · %Cgreen: switch color to green
1006 · %Cblue: switch color to blue
1008 · %Creset: reset color
1010 · %C(...): color specification, as described in color.branch.*
1012 config option; adding auto, at the beginning will emit color
1013 only when colors are enabled for log output (by color.diff,
1014 color.ui, or --color, and respecting the auto settings of the
1015 former if we are going to a terminal). auto alone (i.e.
1016 %C(auto)) will turn on auto coloring on the next placeholders
1017 until the color is switched again.
1018 · %m: left, right or boundary mark
1020 · %n: newline
1022 · %%: a raw %
1024 · %x00: print a byte from a hex code
1026 · %w([<w>[,<i1>[,<i2>]]]): switch line wrapping, like the -w
1028 option of git-shortlog(1).
1029 · %<(<N>[,trunc|ltrunc|mtrunc]): make the next placeholder take
1031 at least N columns, padding spaces on the right if necessary.
1032 Optionally truncate at the beginning (ltrunc), the middle
1033 (mtrunc) or the end (trunc) if the output is longer than N
1034 columns. Note that truncating only works correctly with N >= 2.
1035 · %<|(<N>): make the next placeholder take at least until Nth
1037 columns, padding spaces on the right if necessary
1038 · %>(<N>), %>|(<N>): similar to %<(<N>), %<|(<N>) respectively,
1040 but padding spaces on the left
1041 · %>>(<N>), %>>|(<N>): similar to %>(<N>), %>|(<N>) respectively,
1043 except that if the next placeholder takes more spaces than
1044 given and there are spaces on its left, use those spaces
1045 · %><(<N>), %><|(<N>): similar to % <(<N>), %<|(<N>)
1047 respectively, but padding both sides (i.e. the text is
1048 centered)
1049 Note
1051 Some placeholders may depend on other options given to the revision
1052 traversal engine. For example, the %g* reflog options will insert
1053 an empty string unless we are traversing reflog entries (e.g., by
1054 git log -g). The %d placeholder will use the "short" decoration
1055 format if --decorate was not already provided on the command line.
1056 If you add a + (plus sign) after % of a placeholder, a line-feed is
1058 inserted immediately before the expansion if and only if the
1059 placeholder expands to a non-empty string.
1060 If you add a - (minus sign) after % of a placeholder, line-feeds that
1062 immediately precede the expansion are deleted if and only if the
1063 placeholder expands to an empty string.
1064 If you add a ` ` (space) after % of a placeholder, a space is inserted
1066 immediately before the expansion if and only if the placeholder expands
1067 to a non-empty string.
1068 · tformat:
1070 The tformat: format works exactly like format:, except that it
1072 provides "terminator" semantics instead of "separator" semantics.
1073 In other words, each commit has the message terminator character
1074 (usually a newline) appended, rather than a separator placed
1075 between entries. This means that the final entry of a single-line
1076 format will be properly terminated with a new line, just as the
1077 "oneline" format does. For example:
1078 $ git log -2 --pretty=format:%h 4da45bef \
1080 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
1081 4da45be
1082 7134973 -- NO NEWLINE
1083 $ git log -2 --pretty=tformat:%h 4da45bef \
1085 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
1086 4da45be
1087 7134973
1088 In addition, any unrecognized string that has a % in it is
1090 interpreted as if it has tformat: in front of it. For example,
1091 these two are equivalent:
1092 $ git log -2 --pretty=tformat:%h 4da45bef
1094 $ git log -2 --pretty=%h 4da45bef
1095
1098 Part of the git(1) suite
1099Git 1.8.3.1 11/19/2018 GIT-REV-LIST(1)