1GIT-REV-LIST(1) Git Manual GIT-REV-LIST(1)
2
3
4
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
49
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
56 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
63 Thus, the following command:
64
65 $ git rev-list foo bar ^baz
66
67
68 means "list all the commits which are reachable from foo or bar, but
69 not from baz".
70
71 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
75 $ git rev-list origin..HEAD
76 $ git rev-list HEAD ^origin
77
78
79 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
83 $ git rev-list A B --not $(git merge-base --all A B)
84 $ git rev-list A...B
85
86
87 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
99 -n number, --max-count=<number>
100 Limit the number of commits to output.
101
102 --skip=<number>
103 Skip number commits before starting to show the commit output.
104
105 --since=<date>, --after=<date>
106 Show commits more recent than a specific date.
107
108 --until=<date>, --before=<date>
109 Show commits older than a specific date.
110
111 --max-age=<timestamp>, --min-age=<timestamp>
112 Limit the commits output to specified time range.
113
114 --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
118 --grep=<pattern>
119 Limit the commits output to ones with log message that matches the
120 specified pattern (regular expression).
121
122 --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
126 -i, --regexp-ignore-case
127 Match the regexp limiting patterns without regard to letters case.
128
129 -E, --extended-regexp
130 Consider the limiting patterns to be extended regular expressions
131 instead of the default basic regular expressions.
132
133 -F, --fixed-strings
134 Consider the limiting patterns to be fixed strings (don’t interpret
135 pattern as a regular expression).
136
137 --remove-empty
138 Stop when a given path disappears from the tree.
139
140 --merges
141 Print only merge commits.
142
143 --no-merges
144 Do not print commits with more than one parent.
145
146 --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
154 --not
155 Reverses the meaning of the ^ prefix (or lack thereof) for all
156 following revision specifiers, up to the next --not.
157
158 --all
159 Pretend as if all the refs in refs/ are listed on the command line
160 as <commit>.
161
162 --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
168 --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
174 --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
180 --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
186 --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
191 --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
198 --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
203 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
210 -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
216 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
225 --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
229 --boundary
230 Output uninteresting commits at the boundary, which are usually not
231 shown.
232
233 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
240 The following options select the commits to be shown:
241
242 <paths>
243 Commits modifying the given <paths> are selected.
244
245 --simplify-by-decoration
246 Commits that are referred by some branch or tag are selected.
247
248 Note that extra commits can be shown to give a meaningful history.
249
250 The following options affect the way the simplification is performed:
251
252 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
258 --full-history
259 As the default mode but does not prune some history.
260
261 --dense
262 Only the selected commits are shown, plus some to have a meaningful
263 history.
264
265 --sparse
266 All commits in the simplified history are shown.
267
268 --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
273 --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
279 A more detailed explanation follows.
280
281 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
285 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
289 .-A---M---N---O---P
290 / / / / /
291 I B C D E
292 \ / / / /
293 `-------------'
294
295
296 The horizontal line of history A—P is taken to be the first parent of
297 each merge. The commits are:
298
299 · 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
303 · In A, foo contains just "foo".
304
305 · B contains the same change as A. Its merge M is trivial and hence
306 TREESAME to all parents.
307
308 · C does not change foo, but its merge N changes it to "foobar", so
309 it is not TREESAME to any parent.
310
311 · 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
314 · 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
318 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
323 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
330 This results in:
331
332 .-A---N---O
333 / / /
334 I---------D
335
336 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
341 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
345 --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
351 I A B N D O
352
353 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
357 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
361 --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
365 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
369 .-A---M---N---O---P
370 / / / / /
371 I B / D /
372 \ / / / /
373 `-------------'
374
375 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
380 In addition to the above settings, you can change whether TREESAME
381 affects inclusion:
382
383 --dense
384 Commits that are walked are included if they are not TREESAME to
385 any parent.
386
387 --sparse
388 All commits that are walked are included.
389
390 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
394 --simplify-merges
395 First, build a history graph in the same way that --full-history
396 with parent rewriting does (see above).
397
398 Then simplify each commit ‘C` to its replacement C’ in the final
399 history according to the following rules:
400
401 · Set ‘C’` to C.
402
403 · 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
407 · 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
411 The effect of this is best shown by way of comparing to
412 --full-history with parent rewriting. The example turns into:
413
414 .-A---M---N---O
415 / / /
416 I B D
417 \ / /
418 `---------'
419
420 Note the major differences in N and P over --full-history:
421
422 · 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
425 · P's parent list similarly had I removed. P was then removed
426 completely, because it had one parent and is TREESAME.
427
428 Finally, there is a fifth simplification mode available:
429
430 --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
436 As an example use case, consider the following commit history:
437
438 D---E-------F
439 / \ \
440 B---C---G---H---I---J
441 / \
442 A-------K---------------L--M
443
444 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
451 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
457 E-------F
458 \ \
459 G---H---I---J
460 \
461 L--M
462
463
464 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
472 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
481 $ git rev-list --bisect foo ^bar ^baz
482
483
484 outputs midpoint, the output of the two commands
485
486 $ git rev-list foo ^midpoint
487 $ git rev-list midpoint ^bar ^baz
488
489
490 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
495 --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
507 --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
514 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
518 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
522 Commit Ordering
523 By default, the commits are shown in reverse chronological order.
524
525 --topo-order
526 This option makes them appear in topological order (i.e. descendant
527 commits are shown before their parents).
528
529 --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
534 --reverse
535 Output the commits in reverse order. Cannot be combined with
536 --walk-reflogs.
537
538 Object Traversal
539 These options are mostly targeted for packing of git repositories.
540
541 --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
547 --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
554 --unpacked
555 Only useful with --objects; print the object IDs that are not in
556 packs.
557
558 --no-walk
559 Only show the given revs, but do not traverse their ancestors.
560
561 --do-walk
562 Overrides a previous --no-walk.
563
564 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
569 --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
576 Note: you can specify the default pretty format in the repository
577 configuration (see git-config(1)).
578
579 --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
585 This should make "--pretty=oneline" a whole lot more readable for
586 people using 80-column terminals.
587
588 --oneline
589 This is a shorthand for "--pretty=oneline --abbrev-commit" used
590 together.
591
592 --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
598 --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
604 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
607 --[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
612 --relative-date
613 Synonym for --date=relative.
614
615 --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
620 --date=relative shows dates relative to the current time, e.g. "2
621 hours ago".
622
623 --date=local shows timestamps in user’s local timezone.
624
625 --date=iso (or --date=iso8601) shows timestamps in ISO 8601 format.
626
627 --date=rfc (or --date=rfc2822) shows timestamps in RFC 2822 format,
628 often found in E-mail messages.
629
630 --date=short shows only date but not time, in YYYY-MM-DD format.
631
632 --date=raw shows the date in the internal raw git format %s %z
633 format.
634
635 --date=default shows timestamps in the original timezone (either
636 committer’s or author’s).
637
638 --header
639 Print the contents of the commit in raw-format; each record is
640 separated with a NUL character.
641
642 --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
647 --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
652 --timestamp
653 Print the raw commit timestamp.
654
655 --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
661 For example, if you have this topology:
662
663 y---b---b branch B
664 / \ /
665 / .
666 / / \
667 o---x---a---a branch A
668
669 you would get an output like this:
670
671 $ git rev-list --left-right --boundary --pretty=oneline A...B
672
673 >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
680
681 --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
687 This enables parent rewriting, see History Simplification below.
688
689 This implies the --topo-order option by default, but the
690 --date-order option may also be specified.
691
692 --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
707 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
712 · oneline
713
714 <sha1> <title line>
715
716 This is designed to be as compact as possible.
717
718 · short
719
720 commit <sha1>
721 Author: <author>
722
723 <title line>
724
725 · medium
726
727 commit <sha1>
728 Author: <author>
729 Date: <author date>
730
731 <title line>
732
733 <full commit message>
734
735 · full
736
737 commit <sha1>
738 Author: <author>
739 Commit: <committer>
740
741 <title line>
742
743 <full commit message>
744
745 · fuller
746
747 commit <sha1>
748 Author: <author>
749 AuthorDate: <author date>
750 Commit: <committer>
751 CommitDate: <committer date>
752
753 <title line>
754
755 <full commit message>
756
757 · email
758
759 From <sha1> <date>
760 From: <author>
761 Date: <author date>
762 Subject: [PATCH] <title line>
763
764 <full commit message>
765
766 · raw
767
768 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
774 · format:<string>
775
776 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
780 E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
781 would show something like this:
782
783 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
786 The placeholders are:
787
788 · %H: commit hash
789
790 · %h: abbreviated commit hash
791
792 · %T: tree hash
793
794 · %t: abbreviated tree hash
795
796 · %P: parent hashes
797
798 · %p: abbreviated parent hashes
799
800 · %an: author name
801
802 · %aN: author name (respecting .mailmap, see git-shortlog(1) or
803 git-blame(1))
804
805 · %ae: author email
806
807 · %aE: author email (respecting .mailmap, see git-shortlog(1) or
808 git-blame(1))
809
810 · %ad: author date (format respects --date= option)
811
812 · %aD: author date, RFC2822 style
813
814 · %ar: author date, relative
815
816 · %at: author date, UNIX timestamp
817
818 · %ai: author date, ISO 8601 format
819
820 · %cn: committer name
821
822 · %cN: committer name (respecting .mailmap, see git-shortlog(1)
823 or git-blame(1))
824
825 · %ce: committer email
826
827 · %cE: committer email (respecting .mailmap, see git-shortlog(1)
828 or git-blame(1))
829
830 · %cd: committer date
831
832 · %cD: committer date, RFC2822 style
833
834 · %cr: committer date, relative
835
836 · %ct: committer date, UNIX timestamp
837
838 · %ci: committer date, ISO 8601 format
839
840 · %d: ref names, like the --decorate option of git-log(1)
841
842 · %e: encoding
843
844 · %s: subject
845
846 · %f: sanitized subject line, suitable for a filename
847
848 · %b: body
849
850 · %B: raw body (unwrapped subject and body)
851
852 · %N: commit notes
853
854 · %gD: reflog selector, e.g., refs/stash@{1}
855
856 · %gd: shortened reflog selector, e.g., stash@{1}
857
858 · %gs: reflog subject
859
860 · %Cred: switch color to red
861
862 · %Cgreen: switch color to green
863
864 · %Cblue: switch color to blue
865
866 · %Creset: reset color
867
868 · %C(...): color specification, as described in color.branch.*
869 config option
870
871 · %m: left, right or boundary mark
872
873 · %n: newline
874
875 · %%: a raw %
876
877 · %x00: print a byte from a hex code
878
879 · %w([<w>[,<i1>[,<i2>]]]): switch line wrapping, like the -w
880 option of git-shortlog(1).
881
882 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
889 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
893 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
897 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
901 · tformat:
902
903 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
911 $ git log -2 --pretty=format:%h 4da45bef \
912 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
913 4da45be
914 7134973 -- NO NEWLINE
915
916 $ git log -2 --pretty=tformat:%h 4da45bef \
917 | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
918 4da45be
919 7134973
920
921 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
925 $ git log -2 --pretty=tformat:%h 4da45bef
926 $ git log -2 --pretty=%h 4da45bef
927
928
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
943 2. git@vger.kernel.org
944 mailto:git@vger.kernel.org
945
946
947
948Git 1.7.4.4 04/11/2011 GIT-REV-LIST(1)