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 Formatting
94 Using these options, git-rev-list(1) will act similar to the more
95 specialized family of commit log tools: git-log(1), git-show(1), and
96 git-whatchanged(1)
97 --pretty[=<format>], --format[=<format>]
99 Pretty-print the contents of the commit logs in a given format,
100 where <format> can be one of oneline, short, medium, full, fuller,
101 email, raw and format:<string>. When omitted, the format defaults
102 to medium.
103 Note: you can specify the default pretty format in the repository
105 configuration (see git-config(1)).
106 --abbrev-commit
108 Instead of showing the full 40-byte hexadecimal commit object name,
109 show only a partial prefix. Non default number of digits can be
110 specified with "--abbrev=<n>" (which also modifies diff output, if
111 it is displayed).
112 This should make "--pretty=oneline" a whole lot more readable for
114 people using 80-column terminals.
115 --oneline
117 This is a shorthand for "--pretty=oneline --abbrev-commit" used
118 together.
119 --encoding[=<encoding>]
121 The commit objects record the encoding used for the log message in
122 their encoding header; this option can be used to tell the command
123 to re-code the commit log message in the encoding preferred by the
124 user. For non plumbing commands this defaults to UTF-8.
125 --no-notes, --show-notes[=<ref>]
127 Show the notes (see git-notes(1)) that annotate the commit, when
128 showing the commit log message. This is the default for git log,
129 git show and git whatchanged commands when there is no --pretty,
130 --format nor --oneline option is given on the command line.
131 With an optional argument, add this ref to the list of notes. The
133 ref is taken to be in refs/notes/ if it is not qualified.
134 --[no-]standard-notes
136 Enable or disable populating the notes ref list from the
137 core.notesRef and notes.displayRef variables (or corresponding
138 environment overrides). Enabled by default. See git-config(1).
139 --relative-date
141 Synonym for --date=relative.
142 --date={relative,local,default,iso,rfc,short,raw}
144 Only takes effect for dates shown in human-readable format, such as
145 when using "--pretty". log.date config variable sets a default
146 value for log command’s --date option.
147 --date=relative shows dates relative to the current time, e.g. "2
149 hours ago".
150 --date=local shows timestamps in user’s local timezone.
152 --date=iso (or --date=iso8601) shows timestamps in ISO 8601 format.
154 --date=rfc (or --date=rfc2822) shows timestamps in RFC 2822 format,
156 often found in E-mail messages.
157 --date=short shows only date but not time, in YYYY-MM-DD format.
159 --date=raw shows the date in the internal raw git format %s %z
161 format.
162 --date=default shows timestamps in the original timezone (either
164 committer’s or author’s).
165 --header
167 Print the contents of the commit in raw-format; each record is
168 separated with a NUL character.
169 --parents
171 Print the parents of the commit. Also enables parent rewriting, see
172 History Simplification below.
173 --children
175 Print the children of the commit. Also enables parent rewriting,
176 see History Simplification below.
177 --timestamp
179 Print the raw commit timestamp.
180 --left-right
182 Mark which side of a symmetric diff a commit is reachable from.
183 Commits from the left side are prefixed with < and those from the
184 right with >. If combined with --boundary, those commits are
185 prefixed with -.
186 For example, if you have this topology:
188 y---b---b branch B
190 / \ /
191 / .
192 / / \
193 o---x---a---a branch A
194 you would get an output like this:
196 $ git rev-list --left-right --boundary --pretty=oneline A...B
198 >bbbbbbb... 3rd on b
200 >bbbbbbb... 2nd on b
201 <aaaaaaa... 3rd on a
202 <aaaaaaa... 2nd on a
203 -yyyyyyy... 1st on b
204 -xxxxxxx... 1st on a
205 --graph
208 Draw a text-based graphical representation of the commit history on
209 the left hand side of the output. This may cause extra lines to be
210 printed in between commits, in order for the graph history to be
211 drawn properly.
212 This implies the --topo-order option by default, but the
214 --date-order option may also be specified.
215 Commit Limiting
217 Besides specifying a range of commits that should be listed using the
218 special notations explained in the description, additional commit
219 limiting may be applied.
220 -n number, --max-count=<number>
222 Limit the number of commits output.
223 --skip=<number>
225 Skip number commits before starting to show the commit output.
226 --since=<date>, --after=<date>
228 Show commits more recent than a specific date.
229 --until=<date>, --before=<date>
231 Show commits older than a specific date.
232 --max-age=<timestamp>, --min-age=<timestamp>
234 Limit the commits output to specified time range.
235 --author=<pattern>, --committer=<pattern>
237 Limit the commits output to ones with author/committer header lines
238 that match the specified pattern (regular expression).
239 --grep=<pattern>
241 Limit the commits output to ones with log message that matches the
242 specified pattern (regular expression).
243 --all-match
245 Limit the commits output to ones that match all given --grep,
246 --author and --committer instead of ones that match at least one.
247 -i, --regexp-ignore-case
249 Match the regexp limiting patterns without regard to letters case.
250 -E, --extended-regexp
252 Consider the limiting patterns to be extended regular expressions
253 instead of the default basic regular expressions.
254 -F, --fixed-strings
256 Consider the limiting patterns to be fixed strings (don’t interpret
257 pattern as a regular expression).
258 --remove-empty
260 Stop when a given path disappears from the tree.
261 --merges
263 Print only merge commits.
264 --no-merges
266 Do not print commits with more than one parent.
267 --first-parent
269 Follow only the first parent commit upon seeing a merge commit.
270 This option can give a better overview when viewing the evolution
271 of a particular topic branch, because merges into a topic branch
272 tend to be only about adjusting to updated upstream from time to
273 time, and this option allows you to ignore the individual commits
274 brought in to your history by such a merge.
275 --not
277 Reverses the meaning of the ^ prefix (or lack thereof) for all
278 following revision specifiers, up to the next --not.
279 --all
281 Pretend as if all the refs in refs/ are listed on the command line
282 as <commit>.
283 --branches[=pattern]
285 Pretend as if all the refs in refs/heads are listed on the command
286 line as <commit>. If pattern is given, limit branches to ones
287 matching given shell glob. If pattern lacks ?, , or [, / at the end
288 is implied.
289 --tags[=pattern]
291 Pretend as if all the refs in refs/tags are listed on the command
292 line as <commit>. If pattern is given, limit tags to ones matching
293 given shell glob. If pattern lacks ?, , or [, / at the end is
294 implied.
295 --remotes[=pattern]
297 Pretend as if all the refs in refs/remotes are listed on the
298 command line as <commit>. If `pattern`is given, limit remote
299 tracking branches to ones matching given shell glob. If pattern
300 lacks ?, , or [, / at the end is implied.
301 --glob=glob-pattern
303 Pretend as if all the refs matching shell glob glob-pattern are
304 listed on the command line as <commit>. Leading refs/, is
305 automatically prepended if missing. If pattern lacks ?, , or [, /
306 at the end is implied.
307 --stdin
309 In addition to the <commit> listed on the command line, read them
310 from the standard input. If a -- separator is seen, stop reading
311 commits and start reading paths to limit the result.
312 --quiet
314 Don’t print anything to standard output. This form is primarily
315 meant to allow the caller to test the exit status to see if a range
316 of objects is fully connected (or not). It is faster than
317 redirecting stdout to /dev/null as the output does not have to be
318 formatted.
319 --cherry-pick
321 Omit any commit that introduces the same change as another commit
322 on the "other side" when the set of commits are limited with
323 symmetric difference.
324 For example, if you have two branches, A and B, a usual way to list
326 all commits on only one side of them is with --left-right, like the
327 example above in the description of that option. It however shows
328 the commits that were cherry-picked from the other branch (for
329 example, "3rd on b" may be cherry-picked from branch A). With this
330 option, such pairs of commits are excluded from the output.
331 -g, --walk-reflogs
333 Instead of walking the commit ancestry chain, walk reflog entries
334 from the most recent one to older ones. When this option is used
335 you cannot specify commits to exclude (that is, ^commit,
336 commit1..commit2, nor commit1...commit2 notations cannot be used).
337 With --pretty format other than oneline (for obvious reasons), this
339 causes the output to have two extra lines of information taken from
340 the reflog. By default, commit@{Nth} notation is used in the
341 output. When the starting commit is specified as commit@{now},
342 output also uses commit@{timestamp} notation instead. Under
343 --pretty=oneline, the commit message is prefixed with this
344 information on the same line. This option cannot be combined with
345 --reverse. See also git-reflog(1).
346 --merge
348 After a failed merge, show refs that touch files having a conflict
349 and don’t exist on all heads to merge.
350 --boundary
352 Output uninteresting commits at the boundary, which are usually not
353 shown.
354 History Simplification
356 Sometimes you are only interested in parts of the history, for example
357 the commits modifying a particular <path>. But there are two parts of
358 History Simplification, one part is selecting the commits and the other
359 is how to do it, as there are various strategies to simplify the
360 history.
361 The following options select the commits to be shown:
363 <paths>
365 Commits modifying the given <paths> are selected.
366 --simplify-by-decoration
368 Commits that are referred by some branch or tag are selected.
369 Note that extra commits can be shown to give a meaningful history.
371 The following options affect the way the simplification is performed:
373 Default mode
375 Simplifies the history to the simplest history explaining the final
376 state of the tree. Simplest because it prunes some side branches if
377 the end result is the same (i.e. merging branches with the same
378 content)
379 --full-history
381 As the default mode but does not prune some history.
382 --dense
384 Only the selected commits are shown, plus some to have a meaningful
385 history.
386 --sparse
388 All commits in the simplified history are shown.
389 --simplify-merges
391 Additional option to --full-history to remove some needless merges
392 from the resulting history, as there are no selected commits
393 contributing to this merge.
394 A more detailed explanation follows.
396 Suppose you specified foo as the <paths>. We shall call commits that
398 modify foo !TREESAME, and the rest TREESAME. (In a diff filtered for
399 foo, they look different and equal, respectively.)
400 In the following, we will always refer to the same example history to
402 illustrate the differences between simplification settings. We assume
403 that you are filtering for a file foo in this commit graph:
404 .-A---M---N---O---P
406 / / / / /
407 I B C D E
408 \ / / / /
409 `-------------´
410 The horizontal line of history A—P is taken to be the first parent of
413 each merge. The commits are:
414 · I is the initial commit, in which foo exists with contents "asdf",
416 and a file quux exists with contents "quux". Initial commits are
417 compared to an empty tree, so I is !TREESAME.
418 · In A, foo contains just "foo".
420 · B contains the same change as A. Its merge M is trivial and hence
422 TREESAME to all parents.
423 · C does not change foo, but its merge N changes it to "foobar", so
425 it is not TREESAME to any parent.
426 · D sets foo to "baz". Its merge O combines the strings from N and D
428 to "foobarbaz"; i.e., it is not TREESAME to any parent.
429 · E changes quux to "xyzzy", and its merge P combines the strings to
431 "quux xyzzy". Despite appearing interesting, P is TREESAME to all
432 parents.
433 rev-list walks backwards through history, including or excluding
435 commits based on whether --full-history and/or parent rewriting (via
436 --parents or --children) are used. The following settings are
437 available.
438 Default mode
440 Commits are included if they are not TREESAME to any parent (though
441 this can be changed, see --sparse below). If the commit was a
442 merge, and it was TREESAME to one parent, follow only that parent.
443 (Even if there are several TREESAME parents, follow only one of
444 them.) Otherwise, follow all parents.
445 This results in:
447 .-A---N---O
449 / /
450 I---------D
451 Note how the rule to only follow the TREESAME parent, if one is
453 available, removed B from consideration entirely. C was considered
454 via N, but is TREESAME. Root commits are compared to an empty tree,
455 so I is !TREESAME.
456 Parent/child relations are only visible with --parents, but that
458 does not affect the commits selected in default mode, so we have
459 shown the parent lines.
460 --full-history without parent rewriting
462 This mode differs from the default in one point: always follow all
463 parents of a merge, even if it is TREESAME to one of them. Even if
464 more than one side of the merge has commits that are included, this
465 does not imply that the merge itself is! In the example, we get
466 I A B N D O
468 P and M were excluded because they are TREESAME to a parent. E, C
470 and B were all walked, but only B was !TREESAME, so the others do
471 not appear.
472 Note that without parent rewriting, it is not really possible to
474 talk about the parent/child relationships between the commits, so
475 we show them disconnected.
476 --full-history with parent rewriting
478 Ordinary commits are only included if they are !TREESAME (though
479 this can be changed, see --sparse below).
480 Merges are always included. However, their parent list is
482 rewritten: Along each parent, prune away commits that are not
483 included themselves. This results in
484 .-A---M---N---O---P
486 / / / / /
487 I B / D /
488 \ / / / /
489 `-------------´
490 Compare to --full-history without rewriting above. Note that E was
492 pruned away because it is TREESAME, but the parent list of P was
493 rewritten to contain E´s parent I. The same happened for C and N.
494 Note also that P was included despite being TREESAME.
495 In addition to the above settings, you can change whether TREESAME
497 affects inclusion:
498 --dense
500 Commits that are walked are included if they are not TREESAME to
501 any parent.
502 --sparse
504 All commits that are walked are included.
505 Note that without --full-history, this still simplifies merges: if
507 one of the parents is TREESAME, we follow only that one, so the
508 other sides of the merge are never walked.
509 Finally, there is a fourth simplification mode available:
511 --simplify-merges
513 First, build a history graph in the same way that --full-history
514 with parent rewriting does (see above).
515 Then simplify each commit ‘C` to its replacement C’ in the final
517 history according to the following rules:
518 · Set ‘C’` to C.
520 · Replace each parent ‘P` of C’ with its simplification ‘P’`. In
522 the process, drop parents that are ancestors of other parents,
523 and remove duplicates.
524 · If after this parent rewriting, ‘C’` is a root or merge commit
526 (has zero or >1 parents), a boundary commit, or !TREESAME, it
527 remains. Otherwise, it is replaced with its only parent.
528 The effect of this is best shown by way of comparing to
529 --full-history with parent rewriting. The example turns into:
530 .-A---M---N---O
532 / / /
533 I B D
534 \ / /
535 `---------´
536 Note the major differences in N and P over --full-history:
538 · N´s parent list had I removed, because it is an ancestor
540 of the other parent M. Still, N remained because it is
541 !TREESAME.
542 · P´s parent list similarly had I removed. P was then
544 removed completely, because it had one parent and is
545 TREESAME.
546 The --simplify-by-decoration option allows you to view only the big
548 picture of the topology of the history, by omitting commits that
549 are not referenced by tags. Commits are marked as !TREESAME (in
550 other words, kept after history simplification rules described
551 above) if (1) they are referenced by tags, or (2) they change the
552 contents of the paths given on the command line. All other commits
553 are marked as TREESAME (subject to be simplified away).
554 Bisection Helpers
556 --bisect
557 Limit output to the one commit object which is roughly halfway
558 between included and excluded commits. Note that the bad bisection
559 ref refs/bisect/bad is added to the included commits (if it exists)
560 and the good bisection refs refs/bisect/good-* are added to the
561 excluded commits (if they exist). Thus, supposing there are no refs
562 in refs/bisect/, if
563 $ git rev-list --bisect foo ^bar ^baz
565 outputs midpoint, the output of the two commands
568 $ git rev-list foo ^midpoint
570 $ git rev-list midpoint ^bar ^baz
571 would be of roughly the same length. Finding the change which
574 introduces a regression is thus reduced to a binary search: repeatedly
575 generate and test new ´midpoint’s until the commit chain is of length
576 one.
577 --bisect-vars
579 This calculates the same as --bisect, except that refs in
580 refs/bisect/ are not used, and except that this outputs text ready
581 to be eval’ed by the shell. These lines will assign the name of the
582 midpoint revision to the variable bisect_rev, and the expected
583 number of commits to be tested after bisect_rev is tested to
584 bisect_nr, the expected number of commits to be tested if
585 bisect_rev turns out to be good to bisect_good, the expected number
586 of commits to be tested if bisect_rev turns out to be bad to
587 bisect_bad, and the number of commits we are bisecting right now to
588 bisect_all.
589 --bisect-all
591 This outputs all the commit objects between the included and
592 excluded commits, ordered by their distance to the included and
593 excluded commits. Refs in refs/bisect/ are not used. The farthest
594 from them is displayed first. (This is the only one displayed by
595 --bisect.)
596 This is useful because it makes it easy to choose a good commit to
598 test when you want to avoid to test some of them for some reason
599 (they may not compile for example).
600 This option can be used along with --bisect-vars, in this case,
602 after all the sorted commit objects, there will be the same text as
603 if --bisect-vars had been used alone.
604 Commit Ordering
606 By default, the commits are shown in reverse chronological order.
607 --topo-order
609 This option makes them appear in topological order (i.e. descendant
610 commits are shown before their parents).
611 --date-order
613 This option is similar to --topo-order in the sense that no parent
614 comes before all of its children, but otherwise things are still
615 ordered in the commit timestamp order.
616 --reverse
618 Output the commits in reverse order. Cannot be combined with
619 --walk-reflogs.
620 Object Traversal
622 These options are mostly targeted for packing of git repositories.
623 --objects
625 Print the object IDs of any object referenced by the listed
626 commits. --objects foo ^bar thus means "send me all object IDs
627 which I need to download if I have the commit object bar, but not
628 foo".
629 --objects-edge
631 Similar to --objects, but also print the IDs of excluded commits
632 prefixed with a "-" character. This is used by git-pack-objects(1)
633 to build "thin" pack, which records objects in deltified form based
634 on objects contained in these excluded commits to reduce network
635 traffic.
636 --unpacked
638 Only useful with --objects; print the object IDs that are not in
639 packs.
640 --no-walk
642 Only show the given revs, but do not traverse their ancestors.
643 --do-walk
645 Overrides a previous --no-walk.
646
648 If the commit is a merge, and if the pretty-format is not oneline,
649 email or raw, an additional line is inserted before the Author: line.
650 This line begins with "Merge: " and the sha1s of ancestral commits are
651 printed, separated by spaces. Note that the listed commits may not
652 necessarily be the list of the direct parent commits if you have
653 limited your view of history: for example, if you are only interested
654 in changes related to a certain directory or file.
655 Here are some additional details for each format:
657 · oneline
659 <sha1> <title line>
661 This is designed to be as compact as possible.
663 · short
665 commit <sha1>
667 Author: <author>
668 <title line>
670 · medium
672 commit <sha1>
674 Author: <author>
675 Date: <author date>
676 <title line>
678 <full commit message>
680 · full
682 commit <sha1>
684 Author: <author>
685 Commit: <committer>
686 <title line>
688 <full commit message>
690 · fuller
692 commit <sha1>
694 Author: <author>
695 AuthorDate: <author date>
696 Commit: <committer>
697 CommitDate: <committer date>
698 <title line>
700 <full commit message>
702 · email
704 From <sha1> <date>
706 From: <author>
707 Date: <author date>
708 Subject: [PATCH] <title line>
709 <full commit message>
711 · raw
713 The raw format shows the entire commit exactly as stored in the
715 commit object. Notably, the SHA1s are displayed in full, regardless
716 of whether --abbrev or --no-abbrev are used, and parents
717 information show the true parent commits, without taking grafts nor
718 history simplification into account.
719 · format:
721 The format: format allows you to specify which information you want
723 to show. It works a little bit like printf format, with the notable
724 exception that you get a newline with %n instead of \n.
725 E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
727 would show something like this:
728 The author of fe6e0ee was Junio C Hamano, 23 hours ago
730 The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
731 The placeholders are:
733 · %H: commit hash
735 · %h: abbreviated commit hash
737 · %T: tree hash
739 · %t: abbreviated tree hash
741 · %P: parent hashes
743 · %p: abbreviated parent hashes
745 · %an: author name
747 · %aN: author name (respecting .mailmap, see git-shortlog(1) or
749 git-blame(1))
750 · %ae: author email
752 · %aE: author email (respecting .mailmap, see git-shortlog(1) or
754 git-blame(1))
755 · %ad: author date (format respects --date= option)
757 · %aD: author date, RFC2822 style
759 · %ar: author date, relative
761 · %at: author date, UNIX timestamp
763 · %ai: author date, ISO 8601 format
765 · %cn: committer name
767 · %cN: committer name (respecting .mailmap, see git-shortlog(1)
769 or git-blame(1))
770 · %ce: committer email
772 · %cE: committer email (respecting .mailmap, see git-shortlog(1)
774 or git-blame(1))
775 · %cd: committer date
777 · %cD: committer date, RFC2822 style
779 · %cr: committer date, relative
781 · %ct: committer date, UNIX timestamp
783 · %ci: committer date, ISO 8601 format
785 · %d: ref names, like the --decorate option of git-log(1)
787 · %e: encoding
789 · %s: subject
791 · %f: sanitized subject line, suitable for a filename
793 · %b: body
795 · %N: commit notes
797 · %gD: reflog selector, e.g., refs/stash@{1}
799 · %gd: shortened reflog selector, e.g., stash@{1}
801 · %gs: reflog subject
803 · %Cred: switch color to red
805 · %Cgreen: switch color to green
807 · %Cblue: switch color to blue
809 · %Creset: reset color
811 · %C(...): color specification, as described in color.branch.*
813 config option
814 · %m: left, right or boundary mark
816 · %n: newline
818 · %%: a raw %
820 · %x00: print a byte from a hex code
822 · %w([<w>[,<i1>[,<i2>]]]): switch line wrapping, like the -w
824 option of git-shortlog(1).
825 Note
827 Some placeholders may depend on other options given to the revision
828 traversal engine. For example, the %g* reflog options will insert
829 an empty string unless we are traversing reflog entries (e.g., by
830 git log -g). The %d placeholder will use the "short" decoration
831 format if --decorate was not already provided on the command line.
832 If you add a + (plus sign) after % of a placeholder, a line-feed is
834 inserted immediately before the expansion if and only if the
835 placeholder expands to a non-empty string.
836 If you add a - (minus sign) after % of a placeholder, line-feeds that
838 immediately precede the expansion are deleted if and only if the
839 placeholder expands to an empty string.
840 · tformat:
842 The tformat: format works exactly like format:, except that it
844 provides "terminator" semantics instead of "separator" semantics.
845 In other words, each commit has the message terminator character
846 (usually a newline) appended, rather than a separator placed
847 between entries. This means that the final entry of a single-line
848 format will be properly terminated with a new line, just as the
849 "oneline" format does. For example:
850 $ git log -2 --pretty=format:%h 4da45bef \
852 | perl -pe ´$_ .= " -- NO NEWLINE\n" unless /\n/´
853 4da45be
854 7134973 -- NO NEWLINE
855 $ git log -2 --pretty=tformat:%h 4da45bef \
857 | perl -pe ´$_ .= " -- NO NEWLINE\n" unless /\n/´
858 4da45be
859 7134973
860 In addition, any unrecognized string that has a % in it is
862 interpreted as if it has tformat: in front of it. For example,
863 these two are equivalent:
864 $ git log -2 --pretty=tformat:%h 4da45bef
866 $ git log -2 --pretty=%h 4da45bef
867
870 Written by Linus Torvalds <torvalds@osdl.org[1]>
871
873 Documentation by David Greaves, Junio C Hamano, Jonas Fonseca and the
874 git-list <git@vger.kernel.org[2]>.
875
877 Part of the git(1) suite
878
880 1. torvalds@osdl.org
881 mailto:torvalds@osdl.org
882 2. git@vger.kernel.org
884 mailto:git@vger.kernel.org
885Git 1.7.1 08/16/2017 GIT-REV-LIST(1)