blob: 39e62072691d408519ff377cb6e91e8d95175ec4 [file] [log] [blame]
Commit Limiting
Besides specifying a range of commits that should be listed using the
special notations explained in the description, additional commit
limiting may be applied. Note that they are applied before commit
ordering and formatting options, such as '--reverse'.
-n 'number'::
Limit the number of commits to output.
Skip 'number' commits before starting to show the commit output.
Show commits more recent than a specific date.
Show commits older than a specific date.
Limit the commits output to specified time range.
Limit the commits output to ones with author/committer
header lines that match the specified pattern (regular expression).
Limit the commits output to ones with log message that
matches the specified pattern (regular expression).
Match the regexp limiting patterns without regard to letters case.
Consider the limiting patterns to be extended regular expressions
instead of the default basic regular expressions.
Consider the limiting patterns to be fixed strings (don't interpret
pattern as a regular expression).
Stop when a given path disappears from the tree.
Print only merge commits. This is exactly the same as `--min-parents=2`.
Do not print commits with more than one parent. This is
exactly the same as `--max-parents=1`.
commits. In particular, `--max-parents=1` is the same as `--no-merges`,
`--min-parents=2` is the same as `--merges`. `--max-parents=0`
gives all root commits and `--min-parents=3` all octopus merges.
`--no-min-parents` and `--no-max-parents` reset these limits (to no limit)
again. Equivalent forms are `--min-parents=0` (any commit has 0 or more
parents) and `--max-parents=-1` (negative numbers denote no upper limit).
Follow only the first parent commit upon seeing a merge
commit. This option can give a better overview when
viewing the evolution of a particular topic branch,
because merges into a topic branch tend to be only about
adjusting to updated upstream from time to time, and
this option allows you to ignore the individual commits
brought in to your history by such a merge.
Reverses the meaning of the '{caret}' prefix (or lack thereof)
for all following revision specifiers, up to the next '--not'.
Pretend as if all the refs in `refs/` are listed on the
command line as '<commit>'.
Pretend as if all the refs in `refs/heads` are listed
on the command line as '<commit>'. If '<pattern>' is given, limit
branches to ones matching given shell glob. If pattern lacks '?',
'*', or '[', '/*' at the end is implied.
Pretend as if all the refs in `refs/tags` are listed
tags to ones matching given shell glob. If pattern lacks '?', '*',
Pretend as if all the refs in `refs/remotes` are listed
remote-tracking branches to ones matching given shell glob.
If pattern lacks '?', '*', or '[', '/*' at the end is implied.
Pretend as if all the refs matching shell glob '<glob-pattern>'
are listed on the command line as '<commit>'. Leading 'refs/',
is automatically prepended if missing. If pattern lacks '?', '*',
the bad input was not given.
Pretend as if the bad bisection ref `refs/bisect/bad`
was listed and as if it was followed by `--not` and the good
bisection refs `refs/bisect/good-*` on the command
In addition to the '<commit>' listed on the command
line, read them from the standard input. If a '--' separator is
seen, stop reading commits and start reading paths to limit the
Don't print anything to standard output. This form
is primarily meant to allow the caller to
connected (or not). It is faster than redirecting stdout
Like `--cherry-pick` (see below) but mark equivalent commits
with `=` rather than omitting them, and inequivalent ones with `+`.
Omit any commit that introduces the same change as
another commit on the "other side" when the set of
commits are limited with symmetric difference.
For example, if you have two branches, `A` and `B`, a usual way
to list all commits on only one side of them is with
`--left-right` (see the example below in the description of
the `--left-right` option). It however shows the commits that were cherry-picked
excluded from the output.
List only commits on the respective side of a symmetric range,
i.e. only those which would be marked `<` resp. `>` by
For example, `--cherry-pick --right-only A...B` omits those
commits from `B` which are in `A` or are patch-equivalent to a commit in
`A`. In other words, this lists the `{plus}` commits from `git cherry A B`.
More precisely, `--cherry-pick --right-only --no-merges` gives the exact
A synonym for `--right-only --cherry-mark --no-merges`; useful to
have been applied to the other side of a forked history with
`git log --cherry upstream...mybranch`, similar to
`git cherry upstream mybranch`.
Instead of walking the commit ancestry chain, walk
reflog entries from the most recent one to older ones.
When this option is used you cannot specify commits to
exclude (that is, '{caret}commit', 'commit1..commit2',
nor 'commit1\...commit2' notations cannot be used).
With '\--pretty' format other than oneline (for obvious reasons),
this causes the output to have two extra lines of information
taken from the reflog. By default, 'commit@\{Nth}' notation is
used in the output. When the starting commit is specified as
'commit@\{now}', output also uses 'commit@\{timestamp}' notation
instead. Under '\--pretty=oneline', the commit message is
prefixed with this information on the same line.
This option cannot be combined with '\--reverse'.
See also linkgit:git-reflog[1].
After a failed merge, show refs that touch files having a
conflict and don't exist on all heads to merge.
Output uninteresting commits at the boundary, which are usually
not shown.
History Simplification
'History Simplification', one part is selecting the commits and the other
The following options select the commits to be shown:
Commits modifying the given <paths> are selected.
Commits that are referred by some branch or tag are selected.
The following options affect the way the simplification is performed:
Default mode::
Simplifies the history to the simplest history explaining the
final state of the tree. Simplest because it prunes some side
with the same content)
Only the selected commits are shown, plus some to have a
meaningful history.
All commits in the simplified history are shown.
Additional option to '--full-history' to remove some needless
merges from the resulting history, as there are no selected
commits contributing to this merge.
When given a range of commits to display (e.g. 'commit1..commit2'
or 'commit2 {caret}commit1'), only display commits that exist
directly on the ancestry chain between the 'commit1' and
'commit2', i.e. commits that are both descendants of 'commit1',
and ancestors of 'commit2'.
A more detailed explanation follows.
Suppose you specified `foo` as the <paths>. We shall call commits
that modify `foo` !TREESAME, and the rest TREESAME. (In a diff
filtered for `foo`, they look different and equal, respectively.)
illustrate the differences between simplification settings. We assume
that you are filtering for a file `foo` in this commit graph:
/ / / / /
\ / / / /
each merge. The commits are:
hence TREESAME to all parents.
so it is not TREESAME to any parent.
TREESAME to all parents.
are available.
Default mode::
Commits are included if they are not TREESAME to any parent
only that parent. (Even if there are several TREESAME
This results in:
/ / /
empty tree, so `I` is !TREESAME.
parent lines.
--full-history without parent rewriting::
This mode differs from the default in one point: always follow
the example, we get
do not appear.
them disconnected.
--full-history with parent rewriting::
Ordinary commits are only included if they are !TREESAME
Along each parent, prune away commits that are not included
themselves. This results in
/ / / / /
I B / D /
\ / / / /
In addition to the above settings, you can change whether TREESAME
affects inclusion:
Commits that are walked are included if they are not TREESAME
to any parent.
All commits that are walked are included.
sides of the merge are never walked.
First, build a history graph in the same way that
history according to the following rules:
* Set `C'` to `C`.
remove duplicates.
Otherwise, it is replaced with its only parent.
The effect of this is best shown by way of comparing to
/ / /
\ / /
removed completely, because it had one parent and is TREESAME.
Finally, there is a fifth simplification mode available:
Limit the displayed commits to those directly on the ancestry
commit, and descendants of the "from" commit.
As an example use case, consider the following commit history:
/ \ \
/ \
of course).
\ \
big picture of the topology of the history, by omitting commits
(in other words, kept after history simplification rules described
contents of the paths given on the command line. All other
Bisection Helpers
Limit output to the one commit object which is roughly halfway between
included and excluded commits. Note that the bad bisection ref
are no refs in `refs/bisect/`, if
outputs 'midpoint', the output of the two commands
$ git rev-list foo ^midpoint
$ git rev-list midpoint ^bar ^baz
would be of roughly the same length. Finding the change which
introduces a regression is thus reduced to a binary search: repeatedly
This outputs all the commit objects between the included and excluded
commits, ordered by their distance to the included and excluded
may not compile for example).
`--bisect-vars` had been used alone.
Commit Ordering
By default, the commits are shown in reverse chronological order.
This option makes them appear in topological order (i.e.
descendant commits are shown before their parents).
parent comes before all of its children, but otherwise things
are still ordered in the commit timestamp order.
Output the commits in reverse order.
Object Traversal
These options are mostly targeted for packing of git repositories.
Print the object IDs of any object referenced by the listed
object 'bar', but not 'foo'".
objects in deltified form based on objects contained in these
excluded commits to reduce network traffic.
in packs.
Overrides a previous --no-walk.
Commit Formatting
Synonym for `--date=relative`.
value for log command's --date option.
e.g. "2 hours ago".
format, often found in E-mail messages.
(either committer's or author's).
separated with a NUL character.
Also enables parent rewriting, see 'History Simplification' below.
Also enables parent rewriting, see 'History Simplification' below.
Print the raw commit timestamp.
commits are prefixed with `-`.
For example, if you have this topology:
y---b---b branch B
/ \ /
/ .
/ / \
you would get an output like this:
>bbbbbbb... 3rd on b
>bbbbbbb... 2nd on b
<aaaaaaa... 3rd on a
<aaaaaaa... 2nd on a
-yyyyyyy... 1st on b
-xxxxxxx... 1st on a
Draw a text-based graphical representation of the commit history
to be drawn properly.
This enables parent rewriting, see 'History Simplification' below.
Print a number stating how many commits would have been
listed, and suppress all other output. When used together
right commits, separated by a tab. When used together with
counts and print the count for equivalent commits separated
by a tab.
Diff Formatting
Below are listed options that control the formatting of diff output.
With this option, diff output for a merge commit
shows the differences from each of the parents to the merge result
simultaneously instead of showing pairwise diff between a parent
which were modified from all parents.
patch output by omitting uninteresting hunks whose contents in
the parents have only two variants and the merge result picks
one of them without modification.
This flag makes the merge commits show the full diff like
regular commits; for each merge parent, a separate log entry
and diff is generated. An exception is that only diff against
in that case, the output represents the changes the merge
brought _into_ the then-current branch.
Show recursive diffs.
Suppress diff output.