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 [ --first-parent ]
17 [ --remove-empty ]
18 [ --full-history ]
19 [ --not ]
20 [ --all ]
21 [ --branches[=<pattern>] ]
22 [ --tags[=<pattern>] ]
23 [ --remotes[=<pattern>] ]
24 [ --glob=<glob-pattern> ]
25 [ --stdin ]
26 [ --quiet ]
27 [ --topo-order ]
28 [ --parents ]
29 [ --timestamp ]
30 [ --left-right ]
31 [ --cherry-pick ]
32 [ --encoding[=<encoding>] ]
33 [ --(author|committer|grep)=<pattern> ]
34 [ --regexp-ignore-case | -i ]
35 [ --extended-regexp | -E ]
36 [ --fixed-strings | -F ]
37 [ --date=(local|relative|default|iso|rfc|short) ]
38 [ [--objects | --objects-edge] [ --unpacked ] ]
39 [ --pretty | --header ]
40 [ --bisect ]
41 [ --bisect-vars ]
42 [ --bisect-all ]
43 [ --merge ]
44 [ --reverse ]
45 [ --walk-reflogs ]
46 [ --no-walk ] [ --do-walk ]
47 <commit>... [ -- <paths>... ]
48
51 List commits that are reachable by following the parent links from the
52 given commit(s), but exclude commits that are reachable from the one(s)
53 given with a ^ in front of them. The output is given in reverse
54 chronological order by default.
55 You can think of this as a set operation. Commits given on the command
57 line form a set of commits that are reachable from any of them, and
58 then commits reachable from any of the ones given with ^ in front are
59 subtracted from that set. The remaining commits are what comes out in
60 the command’s output. Various other options and paths parameters can be
61 used to further limit the result.
62 Thus, the following command:
64 $ git rev-list foo bar ^baz
66 means "list all the commits which are reachable from foo or bar, but
69 not from baz".
70 A special notation "<commit1>..<commit2>" can be used as a short-hand
72 for "^<commit1> <commit2>". For example, either of the following may be
73 used interchangeably:
74 $ git rev-list origin..HEAD
76 $ git rev-list HEAD ^origin
77 Another special notation is "<commit1>...<commit2>" which is useful for
80 merges. The resulting set of commits is the symmetric difference
81 between the two operands. The following two commands are equivalent:
82 $ git rev-list A B --not $(git merge-base --all A B)
84 $ git rev-list A...B
85 rev-list is a very essential git command, since it provides the ability
88 to build and traverse commit ancestry graphs. For this reason, it has a
89 lot of different options that enables it to be used by commands as
90 different as git bisect and git repack.
91
93 Commit Limiting
94 Besides specifying a range of commits that should be listed using the
95 special notations explained in the description, additional commit
96 limiting may be applied. Note that they are applied before commit
97 ordering and formatting options, such as --reverse.
98 -n number, --max-count=<number>
100 Limit the number of commits to output.
101 --skip=<number>
103 Skip number commits before starting to show the commit output.
104 --since=<date>, --after=<date>
106 Show commits more recent than a specific date.
107 --until=<date>, --before=<date>
109 Show commits older than a specific date.
110 --max-age=<timestamp>, --min-age=<timestamp>
112 Limit the commits output to specified time range.
113 --author=<pattern>, --committer=<pattern>
115 Limit the commits output to ones with author/committer header lines
116 that match the specified pattern (regular expression).
117 --grep=<pattern>
119 Limit the commits output to ones with log message that matches the
120 specified pattern (regular expression).
121 --all-match
123 Limit the commits output to ones that match all given --grep,
124 --author and --committer instead of ones that match at least one.
125 -i, --regexp-ignore-case
127 Match the regexp limiting patterns without regard to letters case.
128 -E, --extended-regexp
130 Consider the limiting patterns to be extended regular expressions
131 instead of the default basic regular expressions.
132 -F, --fixed-strings
134 Consider the limiting patterns to be fixed strings (don’t interpret
135 pattern as a regular expression).
136 --remove-empty
138 Stop when a given path disappears from the tree.
139 --merges
141 Print only merge commits.
142 --no-merges
144 Do not print commits with more than one parent.
145 --first-parent
147 Follow only the first parent commit upon seeing a merge commit.
148 This option can give a better overview when viewing the evolution
149 of a particular topic branch, because merges into a topic branch
150 tend to be only about adjusting to updated upstream from time to
151 time, and this option allows you to ignore the individual commits
152 brought in to your history by such a merge.
153 --not
155 Reverses the meaning of the ^ prefix (or lack thereof) for all
156 following revision specifiers, up to the next --not.
157 --all
159 Pretend as if all the refs in refs/ are listed on the command line
160 as <commit>.
161 --branches[=<pattern>]
163 Pretend as if all the refs in refs/heads are listed on the command
164 line as <commit>. If <pattern> is given, limit branches to ones
165 matching given shell glob. If pattern lacks ?, , or [, / at the end
166 is implied.
167 --tags[=<pattern>]
169 Pretend as if all the refs in refs/tags are listed on the command
170 line as <commit>. If <pattern> is given, limit tags to ones
171 matching given shell glob. If pattern lacks ?, , or [, / at the end
172 is implied.
173 --remotes[=<pattern>]
175 Pretend as if all the refs in refs/remotes are listed on the
176 command line as <commit>. If <pattern> is given, limit
177 remote-tracking branches to ones matching given shell glob. If
178 pattern lacks ?, , or [, / at the end is implied.
179 --glob=<glob-pattern>
181 Pretend as if all the refs matching shell glob <glob-pattern> are
182 listed on the command line as <commit>. Leading refs/, is
183 automatically prepended if missing. If pattern lacks ?, , or [, /
184 at the end is implied.
185 --stdin
187 In addition to the <commit> listed on the command line, read them
188 from the standard input. If a -- separator is seen, stop reading
189 commits and start reading paths to limit the result.
190 --quiet
192 Don’t print anything to standard output. This form is primarily
193 meant to allow the caller to test the exit status to see if a range
194 of objects is fully connected (or not). It is faster than
195 redirecting stdout to /dev/null as the output does not have to be
196 formatted.
197 --cherry-pick
199 Omit any commit that introduces the same change as another commit
200 on the "other side" when the set of commits are limited with
201 symmetric difference.
202 For example, if you have two branches, A and B, a usual way to list
204 all commits on only one side of them is with --left-right, like the
205 example above in the description of that option. It however shows
206 the commits that were cherry-picked from the other branch (for
207 example, "3rd on b" may be cherry-picked from branch A). With this
208 option, such pairs of commits are excluded from the output.
209 -g, --walk-reflogs
211 Instead of walking the commit ancestry chain, walk reflog entries
212 from the most recent one to older ones. When this option is used
213 you cannot specify commits to exclude (that is, ^commit,
214 commit1..commit2, nor commit1...commit2 notations cannot be used).
215 With --pretty format other than oneline (for obvious reasons), this
217 causes the output to have two extra lines of information taken from
218 the reflog. By default, commit@{Nth} notation is used in the
219 output. When the starting commit is specified as commit@{now},
220 output also uses commit@{timestamp} notation instead. Under
221 --pretty=oneline, the commit message is prefixed with this
222 information on the same line. This option cannot be combined with
223 --reverse. See also git-reflog(1).
224 --merge
226 After a failed merge, show refs that touch files having a conflict
227 and don’t exist on all heads to merge.
228 --boundary
230 Output uninteresting commits at the boundary, which are usually not
231 shown.
232 History Simplification
234 Sometimes you are only interested in parts of the history, for example
235 the commits modifying a particular <path>. But there are two parts of
236 History Simplification, one part is selecting the commits and the other
237 is how to do it, as there are various strategies to simplify the
238 history.
239 The following options select the commits to be shown:
241 <paths>
243 Commits modifying the given <paths> are selected.
244 --simplify-by-decoration
246 Commits that are referred by some branch or tag are selected.
247 Note that extra commits can be shown to give a meaningful history.
249 The following options affect the way the simplification is performed:
251 Default mode
253 Simplifies the history to the simplest history explaining the final
254 state of the tree. Simplest because it prunes some side branches if
255 the end result is the same (i.e. merging branches with the same
256 content)
257 --full-history
259 As the default mode but does not prune some history.
260 --dense
262 Only the selected commits are shown, plus some to have a meaningful
263 history.
264 --sparse
266 All commits in the simplified history are shown.
267 --simplify-merges
269 Additional option to --full-history to remove some needless merges
270 from the resulting history, as there are no selected commits
271 contributing to this merge.
272 --ancestry-path
274 When given a range of commits to display (e.g. commit1..commit2 or
275 commit2 ^commit1), only display commits that exist directly on the
276 ancestry chain between the commit1 and commit2, i.e. commits that
277 are both descendants of commit1, and ancestors of commit2.
278 A more detailed explanation follows.
280 Suppose you specified foo as the <paths>. We shall call commits that
282 modify foo !TREESAME, and the rest TREESAME. (In a diff filtered for
283 foo, they look different and equal, respectively.)
284 In the following, we will always refer to the same example history to
286 illustrate the differences between simplification settings. We assume
287 that you are filtering for a file foo in this commit graph:
288 .-A---M---N---O---P
290 / / / / /
291 I B C D E
292 \ / / / /
293 `-------------'
294 The horizontal line of history A—P is taken to be the first parent of
297 each merge. The commits are:
298 · I is the initial commit, in which foo exists with contents "asdf",
300 and a file quux exists with contents "quux". Initial commits are
301 compared to an empty tree, so I is !TREESAME.
302 · In A, foo contains just "foo".
304 · B contains the same change as A. Its merge M is trivial and hence
306 TREESAME to all parents.
307 · C does not change foo, but its merge N changes it to "foobar", so
309 it is not TREESAME to any parent.
310 · D sets foo to "baz". Its merge O combines the strings from N and D
312 to "foobarbaz"; i.e., it is not TREESAME to any parent.
313 · E changes quux to "xyzzy", and its merge P combines the strings to
315 "quux xyzzy". Despite appearing interesting, P is TREESAME to all
316 parents.
317 rev-list walks backwards through history, including or excluding
319 commits based on whether --full-history and/or parent rewriting (via
320 --parents or --children) are used. The following settings are
321 available.
322 Default mode
324 Commits are included if they are not TREESAME to any parent (though
325 this can be changed, see --sparse below). If the commit was a
326 merge, and it was TREESAME to one parent, follow only that parent.
327 (Even if there are several TREESAME parents, follow only one of
328 them.) Otherwise, follow all parents.
329 This results in:
331 .-A---N---O
333 / / /
334 I---------D
335 Note how the rule to only follow the TREESAME parent, if one is
337 available, removed B from consideration entirely. C was considered
338 via N, but is TREESAME. Root commits are compared to an empty tree,
339 so I is !TREESAME.
340 Parent/child relations are only visible with --parents, but that
342 does not affect the commits selected in default mode, so we have
343 shown the parent lines.
344 --full-history without parent rewriting
346 This mode differs from the default in one point: always follow all
347 parents of a merge, even if it is TREESAME to one of them. Even if
348 more than one side of the merge has commits that are included, this
349 does not imply that the merge itself is! In the example, we get
350 I A B N D O
352 P and M were excluded because they are TREESAME to a parent. E, C
354 and B were all walked, but only B was !TREESAME, so the others do
355 not appear.
356 Note that without parent rewriting, it is not really possible to
358 talk about the parent/child relationships between the commits, so
359 we show them disconnected.
360 --full-history with parent rewriting
362 Ordinary commits are only included if they are !TREESAME (though
363 this can be changed, see --sparse below).
364 Merges are always included. However, their parent list is
366 rewritten: Along each parent, prune away commits that are not
367 included themselves. This results in
368 .-A---M---N---O---P
370 / / / / /
371 I B / D /
372 \ / / / /
373 `-------------'
374 Compare to --full-history without rewriting above. Note that E was
376 pruned away because it is TREESAME, but the parent list of P was
377 rewritten to contain E's parent I. The same happened for C and N.
378 Note also that P was included despite being TREESAME.
379 In addition to the above settings, you can change whether TREESAME
381 affects inclusion:
382 --dense
384 Commits that are walked are included if they are not TREESAME to
385 any parent.
386 --sparse
388 All commits that are walked are included.
389 Note that without --full-history, this still simplifies merges: if
391 one of the parents is TREESAME, we follow only that one, so the
392 other sides of the merge are never walked.
393 --simplify-merges
395 First, build a history graph in the same way that --full-history
396 with parent rewriting does (see above).
397 Then simplify each commit ‘C` to its replacement C’ in the final
399 history according to the following rules:
400 · Set ‘C’` to C.
402 · Replace each parent ‘P` of C’ with its simplification ‘P’`. In
404 the process, drop parents that are ancestors of other parents,
405 and remove duplicates.
406 · If after this parent rewriting, ‘C’` is a root or merge commit
408 (has zero or >1 parents), a boundary commit, or !TREESAME, it
409 remains. Otherwise, it is replaced with its only parent.
410 The effect of this is best shown by way of comparing to
412 --full-history with parent rewriting. The example turns into:
413 .-A---M---N---O
415 / / /
416 I B D
417 \ / /
418 `---------'
419 Note the major differences in N and P over --full-history:
421 · N's parent list had I removed, because it is an ancestor of
423 the other parent M. Still, N remained because it is !TREESAME.
424 · P's parent list similarly had I removed. P was then removed
426 completely, because it had one parent and is TREESAME.
427 Finally, there is a fifth simplification mode available:
429 --ancestry-path
431 Limit the displayed commits to those directly on the ancestry chain
432 between the "from" and "to" commits in the given commit range. I.e.
433 only display commits that are ancestor of the "to" commit, and
434 descendants of the "from" commit.
435 As an example use case, consider the following commit history:
437 D---E-------F
439 / \ \
440 B---C---G---H---I---J
441 / \
442 A-------K---------------L--M
443 A regular D..M computes the set of commits that are ancestors of M,
445 but excludes the ones that are ancestors of D. This is useful to
446 see what happened to the history leading to M since D, in the sense
447 that "what does M have that did not exist in D". The result in this
448 example would be all the commits, except A and B (and D itself, of
449 course).
450 When we want to find out what commits in M are contaminated with
452 the bug introduced by D and need fixing, however, we might want to
453 view only the subset of D..M that are actually descendants of D,
454 i.e. excluding C and K. This is exactly what the --ancestry-path
455 option does. Applied to the D..M range, it results in:
456 E-------F
458 \ \
459 G---H---I---J
460 \
461 L--M
462 The --simplify-by-decoration option allows you to view only the big
465 picture of the topology of the history, by omitting commits that are
466 not referenced by tags. Commits are marked as !TREESAME (in other
467 words, kept after history simplification rules described above) if (1)
468 they are referenced by tags, or (2) they change the contents of the
469 paths given on the command line. All other commits are marked as
470 TREESAME (subject to be simplified away).
471 Bisection Helpers
473 --bisect
474 Limit output to the one commit object which is roughly halfway
475 between included and excluded commits. Note that the bad bisection
476 ref refs/bisect/bad is added to the included commits (if it exists)
477 and the good bisection refs refs/bisect/good-* are added to the
478 excluded commits (if they exist). Thus, supposing there are no refs
479 in refs/bisect/, if
480 $ git rev-list --bisect foo ^bar ^baz
482 outputs midpoint, the output of the two commands
485 $ git rev-list foo ^midpoint
487 $ git rev-list midpoint ^bar ^baz
488 would be of roughly the same length. Finding the change which
491 introduces a regression is thus reduced to a binary search: repeatedly
492 generate and test new 'midpoint’s until the commit chain is of length
493 one.
494 --bisect-vars
496 This calculates the same as --bisect, except that refs in
497 refs/bisect/ are not used, and except that this outputs text ready
498 to be eval’ed by the shell. These lines will assign the name of the
499 midpoint revision to the variable bisect_rev, and the expected
500 number of commits to be tested after bisect_rev is tested to
501 bisect_nr, the expected number of commits to be tested if
502 bisect_rev turns out to be good to bisect_good, the expected number
503 of commits to be tested if bisect_rev turns out to be bad to
504 bisect_bad, and the number of commits we are bisecting right now to
505 bisect_all.
506 --bisect-all
508 This outputs all the commit objects between the included and
509 excluded commits, ordered by their distance to the included and
510 excluded commits. Refs in refs/bisect/ are not used. The farthest
511 from them is displayed first. (This is the only one displayed by
512 --bisect.)
513 This is useful because it makes it easy to choose a good commit to
515 test when you want to avoid to test some of them for some reason
516 (they may not compile for example).
517 This option can be used along with --bisect-vars, in this case,
519 after all the sorted commit objects, there will be the same text as
520 if --bisect-vars had been used alone.
521 Commit Ordering
523 By default, the commits are shown in reverse chronological order.
524 --topo-order
526 This option makes them appear in topological order (i.e. descendant
527 commits are shown before their parents).
528 --date-order
530 This option is similar to --topo-order in the sense that no parent
531 comes before all of its children, but otherwise things are still
532 ordered in the commit timestamp order.
533 --reverse
535 Output the commits in reverse order. Cannot be combined with
536 --walk-reflogs.
537 Object Traversal
539 These options are mostly targeted for packing of git repositories.
540 --objects
542 Print the object IDs of any object referenced by the listed
543 commits. --objects foo ^bar thus means "send me all object IDs
544 which I need to download if I have the commit object bar, but not
545 foo".
546 --objects-edge
548 Similar to --objects, but also print the IDs of excluded commits
549 prefixed with a "-" character. This is used by git-pack-objects(1)
550 to build "thin" pack, which records objects in deltified form based
551 on objects contained in these excluded commits to reduce network
552 traffic.
553 --unpacked
555 Only useful with --objects; print the object IDs that are not in
556 packs.
557 --no-walk
559 Only show the given revs, but do not traverse their ancestors.
560 --do-walk
562 Overrides a previous --no-walk.
563 Commit Formatting
565 Using these options, git-rev-list(1) will act similar to the more
566 specialized family of commit log tools: git-log(1), git-show(1), and
567 git-whatchanged(1)
568 --pretty[=<format>], --format=<format>
570 Pretty-print the contents of the commit logs in a given format,
571 where <format> can be one of oneline, short, medium, full, fuller,
572 email, raw and format:<string>. See the "PRETTY FORMATS" section
573 for some additional details for each format. When omitted, the
574 format defaults to medium.
575 Note: you can specify the default pretty format in the repository
577 configuration (see git-config(1)).
578 --abbrev-commit
580 Instead of showing the full 40-byte hexadecimal commit object name,
581 show only a partial prefix. Non default number of digits can be
582 specified with "--abbrev=<n>" (which also modifies diff output, if
583 it is displayed).
584 This should make "--pretty=oneline" a whole lot more readable for
586 people using 80-column terminals.
587 --oneline
589 This is a shorthand for "--pretty=oneline --abbrev-commit" used
590 together.
591 --encoding[=<encoding>]
593 The commit objects record the encoding used for the log message in
594 their encoding header; this option can be used to tell the command
595 to re-code the commit log message in the encoding preferred by the
596 user. For non plumbing commands this defaults to UTF-8.
597 --no-notes, --show-notes[=<ref>]
599 Show the notes (see git-notes(1)) that annotate the commit, when
600 showing the commit log message. This is the default for git log,
601 git show and git whatchanged commands when there is no --pretty,
602 --format nor --oneline option is given on the command line.
603 With an optional argument, add this ref to the list of notes. The
605 ref is taken to be in refs/notes/ if it is not qualified.
606 --[no-]standard-notes
608 Enable or disable populating the notes ref list from the
609 core.notesRef and notes.displayRef variables (or corresponding
610 environment overrides). Enabled by default. See git-config(1).
611 --relative-date
613 Synonym for --date=relative.
614 --date=(relative|local|default|iso|rfc|short|raw)
616 Only takes effect for dates shown in human-readable format, such as
617 when using "--pretty". log.date config variable sets a default
618 value for log command’s --date option.
619 --date=relative shows dates relative to the current time, e.g. "2
621 hours ago".
622 --date=local shows timestamps in user’s local timezone.
624 --date=iso (or --date=iso8601) shows timestamps in ISO 8601 format.
626 --date=rfc (or --date=rfc2822) shows timestamps in RFC 2822 format,
628 often found in E-mail messages.
629 --date=short shows only date but not time, in YYYY-MM-DD format.
631 --date=raw shows the date in the internal raw git format %s %z
633 format.
634 --date=default shows timestamps in the original timezone (either
636 committer’s or author’s).
637 --header
639 Print the contents of the commit in raw-format; each record is
640 separated with a NUL character.
641 --parents
643 Print also the parents of the commit (in the form "commit
644 parent..."). Also enables parent rewriting, see History
645 Simplification below.
646 --children
648 Print also the children of the commit (in the form "commit
649 child..."). Also enables parent rewriting, see History
650 Simplification below.
651 --timestamp
653 Print the raw commit timestamp.
654 --left-right
656 Mark which side of a symmetric diff a commit is reachable from.
657 Commits from the left side are prefixed with < and those from the
658 right with >. If combined with --boundary, those commits are
659 prefixed with -.
660 For example, if you have this topology:
662 y---b---b branch B
664 / \ /
665 / .
666 / / \
667 o---x---a---a branch A
668 you would get an output like this:
670 $ git rev-list --left-right --boundary --pretty=oneline A...B
672 >bbbbbbb... 3rd on b
674 >bbbbbbb... 2nd on b
675 <aaaaaaa... 3rd on a
676 <aaaaaaa... 2nd on a
677 -yyyyyyy... 1st on b
678 -xxxxxxx... 1st on a
679 --graph
682 Draw a text-based graphical representation of the commit history on
683 the left hand side of the output. This may cause extra lines to be
684 printed in between commits, in order for the graph history to be
685 drawn properly.
686 This enables parent rewriting, see History Simplification below.
688 This implies the --topo-order option by default, but the
690 --date-order option may also be specified.
691 --count
693 Print a number stating how many commits would have been listed, and
694 suppress all other output. When used together with --left-right,
695 instead print the counts for left and right commits, separated by a
696 tab.
697
699 If the commit is a merge, and if the pretty-format is not oneline,
700 email or raw, an additional line is inserted before the Author: line.
701 This line begins with "Merge: " and the sha1s of ancestral commits are
702 printed, separated by spaces. Note that the listed commits may not
703 necessarily be the list of the direct parent commits if you have
704 limited your view of history: for example, if you are only interested
705 in changes related to a certain directory or file.
706 There are several built-in formats, and you can define additional
708 formats by setting a pretty.<name> config option to either another
709 format name, or a format: string, as described below (see git-
710 config(1)). Here are the details of the built-in formats:
711 · oneline
713 <sha1> <title line>
715 This is designed to be as compact as possible.
717 · short
719 commit <sha1>
721 Author: <author>
722 <title line>
724 · medium
726 commit <sha1>
728 Author: <author>
729 Date: <author date>
730 <title line>
732 <full commit message>
734 · full
736 commit <sha1>
738 Author: <author>
739 Commit: <committer>
740 <title line>
742 <full commit message>
744 · fuller
746 commit <sha1>
748 Author: <author>
749 AuthorDate: <author date>
750 Commit: <committer>
751 CommitDate: <committer date>
752 <title line>
754 <full commit message>
756 · email
758 From <sha1> <date>
760 From: <author>
761 Date: <author date>
762 Subject: [PATCH] <title line>
763 <full commit message>
765 · raw
767 The raw format shows the entire commit exactly as stored in the
769 commit object. Notably, the SHA1s are displayed in full, regardless
770 of whether --abbrev or --no-abbrev are used, and parents
771 information show the true parent commits, without taking grafts nor
772 history simplification into account.
773 · format:<string>
775 The format:<string> format allows you to specify which information
777 you want to show. It works a little bit like printf format, with
778 the notable exception that you get a newline with %n instead of \n.
779 E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
781 would show something like this:
782 The author of fe6e0ee was Junio C Hamano, 23 hours ago
784 The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
785 The placeholders are:
787 · %H: commit hash
789 · %h: abbreviated commit hash
791 · %T: tree hash
793 · %t: abbreviated tree hash
795 · %P: parent hashes
797 · %p: abbreviated parent hashes
799 · %an: author name
801 · %aN: author name (respecting .mailmap, see git-shortlog(1) or
803 git-blame(1))
804 · %ae: author email
806 · %aE: author email (respecting .mailmap, see git-shortlog(1) or
808 git-blame(1))
809 · %ad: author date (format respects --date= option)
811 · %aD: author date, RFC2822 style
813 · %ar: author date, relative
815 · %at: author date, UNIX timestamp
817 · %ai: author date, ISO 8601 format
819 · %cn: committer name
821 · %cN: committer name (respecting .mailmap, see git-shortlog(1)
823 or git-blame(1))
824 · %ce: committer email
826 · %cE: committer email (respecting .mailmap, see git-shortlog(1)
828 or git-blame(1))
829 · %cd: committer date
831 · %cD: committer date, RFC2822 style
833 · %cr: committer date, relative
835 · %ct: committer date, UNIX timestamp
837 · %ci: committer date, ISO 8601 format
839 · %d: ref names, like the --decorate option of git-log(1)
841 · %e: encoding
843 · %s: subject
845 · %f: sanitized subject line, suitable for a filename
847 · %b: body
849 · %B: raw body (unwrapped subject and body)
851 · %N: commit notes
853 · %gD: reflog selector, e.g., refs/stash@{1}
855 · %gd: shortened reflog selector, e.g., stash@{1}
857 · %gs: reflog subject
859 · %Cred: switch color to red
861 · %Cgreen: switch color to green
863 · %Cblue: switch color to blue
865 · %Creset: reset color
867 · %C(...): color specification, as described in color.branch.*
869 config option
870 · %m: left, right or boundary mark
872 · %n: newline
874 · %%: a raw %
876 · %x00: print a byte from a hex code
878 · %w([<w>[,<i1>[,<i2>]]]): switch line wrapping, like the -w
880 option of git-shortlog(1).
881 Note
883 Some placeholders may depend on other options given to the revision
884 traversal engine. For example, the %g* reflog options will insert
885 an empty string unless we are traversing reflog entries (e.g., by
886 git log -g). The %d placeholder will use the "short" decoration
887 format if --decorate was not already provided on the command line.
888 If you add a + (plus sign) after % of a placeholder, a line-feed is
890 inserted immediately before the expansion if and only if the
891 placeholder expands to a non-empty string.
892 If you add a - (minus sign) after % of a placeholder, line-feeds that
894 immediately precede the expansion are deleted if and only if the
895 placeholder expands to an empty string.
896 If you add a ` ` (space) after % of a placeholder, a space is inserted
898 immediately before the expansion if and only if the placeholder expands
899 to a non-empty string.
900 · tformat:
902 The tformat: format works exactly like format:, except that it
904 provides "terminator" semantics instead of "separator" semantics.
905 In other words, each commit has the message terminator character
906 (usually a newline) appended, rather than a separator placed
907 between entries. This means that the final entry of a single-line
908 format will be properly terminated with a new line, just as the
909 "oneline" format does. For example:
910 $ git log -2 --pretty=format:%h 4da45bef \
912 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
913 4da45be
914 7134973 -- NO NEWLINE
915 $ git log -2 --pretty=tformat:%h 4da45bef \
917 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
918 4da45be
919 7134973
920 In addition, any unrecognized string that has a % in it is
922 interpreted as if it has tformat: in front of it. For example,
923 these two are equivalent:
924 $ git log -2 --pretty=tformat:%h 4da45bef
926 $ git log -2 --pretty=%h 4da45bef
927
930 Written by Linus Torvalds <torvalds@osdl.org[1]>
931
933 Documentation by David Greaves, Junio C Hamano, Jonas Fonseca and the
934 git-list <git@vger.kernel.org[2]>.
935
937 Part of the git(1) suite
938
940 1. torvalds@osdl.org
941 mailto:torvalds@osdl.org
942 2. git@vger.kernel.org
944 mailto:git@vger.kernel.org
945Git 1.7.4.4 04/11/2011 GIT-REV-LIST(1)