2005-09-08 02:26:23 +02:00
|
|
|
git-log(1)
|
|
|
|
|
==========
|
2005-08-15 02:24:36 +02:00
|
|
|
|
|
|
|
|
NAME
|
|
|
|
|
----
|
2005-09-08 02:26:23 +02:00
|
|
|
git-log - Show commit logs
|
2005-08-15 02:24:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
|
--------
|
2011-07-02 04:38:26 +02:00
|
|
|
[verse]
|
2021-11-06 19:48:52 +01:00
|
|
|
'git log' [<options>] [<revision-range>] [[--] <path>...]
|
2005-08-15 02:24:36 +02:00
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
|
-----------
|
2006-04-14 21:59:09 +02:00
|
|
|
Shows the commit logs.
|
|
|
|
|
|
2020-07-09 04:16:48 +02:00
|
|
|
:git-log: 1
|
|
|
|
|
include::rev-list-description.txt[]
|
|
|
|
|
|
2020-07-09 04:16:43 +02:00
|
|
|
The command takes options applicable to the linkgit:git-rev-list[1]
|
2006-04-14 21:59:09 +02:00
|
|
|
command to control what is shown and how, and options applicable to
|
2020-07-09 04:16:43 +02:00
|
|
|
the linkgit:git-diff[1] command to control how the changes
|
2006-04-14 21:59:09 +02:00
|
|
|
each commit introduces are shown.
|
|
|
|
|
|
2005-08-15 02:24:36 +02:00
|
|
|
|
|
|
|
|
OPTIONS
|
|
|
|
|
-------
|
2006-11-22 00:49:15 +01:00
|
|
|
|
2010-07-08 04:14:31 +02:00
|
|
|
--follow::
|
|
|
|
|
Continue listing the history of a file beyond renames
|
|
|
|
|
(works only for a single file).
|
|
|
|
|
|
2010-02-17 19:20:49 +01:00
|
|
|
--no-decorate::
|
2016-05-27 17:56:02 +02:00
|
|
|
--decorate[=short|full|auto|no]::
|
2009-08-15 16:23:12 +02:00
|
|
|
Print out the ref names of any commits that are shown. If 'short' is
|
|
|
|
|
specified, the ref name prefixes 'refs/heads/', 'refs/tags/' and
|
|
|
|
|
'refs/remotes/' will not be printed. If 'full' is specified, the
|
2016-05-27 17:56:02 +02:00
|
|
|
full ref name (including prefix) will be printed. If 'auto' is
|
|
|
|
|
specified, then if the output is going to a terminal, the ref names
|
|
|
|
|
are shown as if 'short' were given, otherwise no ref names are
|
2021-06-08 03:58:40 +02:00
|
|
|
shown. The option `--decorate` is short-hand for `--decorate=short`.
|
|
|
|
|
Default to configuration value of `log.decorate` if configured,
|
|
|
|
|
otherwise, `auto`.
|
2007-05-11 00:09:38 +02:00
|
|
|
|
log: add option to choose which refs to decorate
When `log --decorate` is used, git will decorate commits with all
available refs. While in most cases this may give the desired effect,
under some conditions it can lead to excessively verbose output.
Introduce two command line options, `--decorate-refs=<pattern>` and
`--decorate-refs-exclude=<pattern>` to allow the user to select which
refs are used in decoration.
When "--decorate-refs=<pattern>" is given, only the refs that match the
pattern are used in decoration. The refs that match the pattern when
"--decorate-refs-exclude=<pattern>" is given, are never used in
decoration.
These options follow the same convention for mixing negative and
positive patterns across the system, assuming that the inclusive default
is to match all refs available.
(1) if there is no positive pattern given, pretend as if an
inclusive default positive pattern was given;
(2) for each candidate, reject it if it matches no positive
pattern, or if it matches any one of the negative patterns.
The rules for what is considered a match are slightly different from the
rules used elsewhere.
Commands like `log --glob` assume a trailing '/*' when glob chars are
not present in the pattern. This makes it difficult to specify a single
ref. On the other hand, commands like `describe --match --all` allow
specifying exact refs, but do not have the convenience of allowing
"shorthand refs" like 'refs/heads' or 'heads' to refer to
'refs/heads/*'.
The commands introduced in this patch consider a match if:
(a) the pattern contains globs chars,
and regular pattern matching returns a match.
(b) the pattern does not contain glob chars,
and ref '<pattern>' exists, or if ref exists under '<pattern>/'
This allows both behaviours (allowing single refs and shorthand refs)
yet remaining compatible with existent commands.
Helped-by: Kevin Daudt <me@ikke.info>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Rafael Ascensão <rafa.almas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-21 22:33:41 +01:00
|
|
|
--decorate-refs=<pattern>::
|
|
|
|
|
--decorate-refs-exclude=<pattern>::
|
log: add default decoration filter
When a user runs 'git log', they expect a certain set of helpful
decorations. This includes:
* The HEAD ref
* Branches (refs/heads/)
* Stashes (refs/stash)
* Tags (refs/tags/)
* Remote branches (refs/remotes/)
* Replace refs (refs/replace/ or $GIT_REPLACE_REF_BASE)
Each of these namespaces was selected due to existing test cases that
verify these namespaces appear in the decorations. In particular,
stashes and replace refs can have custom colors from the
color.decorate.<slot> config option.
While one test checks for a decoration from notes, it only applies to
the tip of refs/notes/commit (or its configured ref name). Notes form
their own kind of decoration instead. Modify the expected output for the
tests in t4013 that expect this note decoration. There are several
tests throughout the codebase that verify that --decorate-refs,
--decorate-refs-exclude, and log.excludeDecoration work as designed and
the tests continue to pass without intervention.
However, there are other refs that are less helpful to show as
decoration:
* Prefetch refs (refs/prefetch/)
* Rebase refs (refs/rebase-merge/ and refs/rebase-apply/)
* Bundle refs (refs/bundle/) [!]
[!] The bundle refs are part of a parallel series that bootstraps a repo
from a bundle file, storing the bundle's refs into the repo's
refs/bundle/ namespace.
In the case of prefetch refs, 96eaffebbf3d0 (maintenance: set
log.excludeDecoration durin prefetch, 2021-01-19) added logic to add
refs/prefetch/ to the log.excludeDecoration config option. Additional
feedback pointed out that having such a side-effect can be confusing and
perhaps not helpful to users. Instead, we should hide these ref
namespaces that are being used by Git for internal reasons but are not
helpful for the users to see.
The way to provide a seamless user experience without setting the config
is to modify the default decoration filters to match our expectation of
what refs the user actually wants to see.
In builtin/log.c, after parsing the --decorate-refs and
--decorate-refs-exclude options from the command-line, call
set_default_decoration_filter(). This method populates the exclusions
from log.excludeDecoration, then checks if the list of pattern
modifications are empty. If none are specified, then the default set is
restricted to the set of inclusions mentioned earlier (HEAD, branches,
etc.). A previous change introduced the ref_namespaces array, which
includes all of these currently-used namespaces. The 'decoration' value
is non-zero when that namespace is associated with a special coloring
and fits into the list of "expected" decorations as described above,
which makes the implementation of this filter very simple.
Note that the logic in ref_filter_match() in log-tree.c follows this
matching pattern:
1. If there are exclusion patterns and the ref matches one, then ignore
the decoration.
2. If there are inclusion patterns and the ref matches one, then
definitely include the decoration.
3. If there are config-based exclusions from log.excludeDecoration and
the ref matches one, then ignore the decoration.
With this logic in mind, we need to ensure that we do not populate our
new defaults if any of these filters are manually set. Specifically, if
a user runs
git -c log.excludeDecoration=HEAD log
then we expect the HEAD decoration to not appear. If we left the default
inclusions in the set, then HEAD would match that inclusion before
reaching the config-based exclusions.
A potential alternative would be to check the list of default inclusions
at the end, after the config-based exclusions. This would still create a
behavior change for some uses of --decorate-refs-exclude=<X>, and could
be overwritten somewhat with --decorate-refs=refs/ and
--decorate-refs=HEAD. However, it no longer becomes possible to include
refs outside of the defaults while also excluding some using
log.excludeDecoration.
Another alternative would be to exclude the known namespaces that are
not intended to be shown. This would reduce the visible effect of the
change for expert users who use their own custom ref namespaces. The
implementation change would be very simple to swap due to our use of
ref_namespaces:
int i;
struct string_list *exclude = decoration_filter->exclude_ref_pattern;
/*
* No command-line or config options were given, so
* populate with sensible defaults.
*/
for (i = 0; i < NAMESPACE__COUNT; i++) {
if (ref_namespaces[i].decoration)
continue;
string_list_append(exclude, ref_namespaces[i].ref);
}
The main downside of this approach is that we expect to add new hidden
namespaces in the future, and that means that Git versions will be less
stable in how they behave as those namespaces are added.
It is critical that we provide ways for expert users to disable this
behavior change via command-line options and config keys. These changes
will be implemented in a future change.
Add a test that checks that the defaults are not added when
--decorate-refs is specified. We verify this by showing that HEAD is not
included as it normally would. Also add a test that shows that the
default filter avoids the unwanted decorations from refs/prefetch,
refs/rebase-merge,
and refs/bundle.
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-05 19:58:39 +02:00
|
|
|
For each candidate reference, do not use it for decoration if it
|
log: add option to choose which refs to decorate
When `log --decorate` is used, git will decorate commits with all
available refs. While in most cases this may give the desired effect,
under some conditions it can lead to excessively verbose output.
Introduce two command line options, `--decorate-refs=<pattern>` and
`--decorate-refs-exclude=<pattern>` to allow the user to select which
refs are used in decoration.
When "--decorate-refs=<pattern>" is given, only the refs that match the
pattern are used in decoration. The refs that match the pattern when
"--decorate-refs-exclude=<pattern>" is given, are never used in
decoration.
These options follow the same convention for mixing negative and
positive patterns across the system, assuming that the inclusive default
is to match all refs available.
(1) if there is no positive pattern given, pretend as if an
inclusive default positive pattern was given;
(2) for each candidate, reject it if it matches no positive
pattern, or if it matches any one of the negative patterns.
The rules for what is considered a match are slightly different from the
rules used elsewhere.
Commands like `log --glob` assume a trailing '/*' when glob chars are
not present in the pattern. This makes it difficult to specify a single
ref. On the other hand, commands like `describe --match --all` allow
specifying exact refs, but do not have the convenience of allowing
"shorthand refs" like 'refs/heads' or 'heads' to refer to
'refs/heads/*'.
The commands introduced in this patch consider a match if:
(a) the pattern contains globs chars,
and regular pattern matching returns a match.
(b) the pattern does not contain glob chars,
and ref '<pattern>' exists, or if ref exists under '<pattern>/'
This allows both behaviours (allowing single refs and shorthand refs)
yet remaining compatible with existent commands.
Helped-by: Kevin Daudt <me@ikke.info>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Rafael Ascensão <rafa.almas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-21 22:33:41 +01:00
|
|
|
matches any patterns given to `--decorate-refs-exclude` or if it
|
2020-04-16 16:15:49 +02:00
|
|
|
doesn't match any of the patterns given to `--decorate-refs`. The
|
|
|
|
|
`log.excludeDecoration` config option allows excluding refs from
|
|
|
|
|
the decorations, but an explicit `--decorate-refs` pattern will
|
|
|
|
|
override a match in `log.excludeDecoration`.
|
log: add default decoration filter
When a user runs 'git log', they expect a certain set of helpful
decorations. This includes:
* The HEAD ref
* Branches (refs/heads/)
* Stashes (refs/stash)
* Tags (refs/tags/)
* Remote branches (refs/remotes/)
* Replace refs (refs/replace/ or $GIT_REPLACE_REF_BASE)
Each of these namespaces was selected due to existing test cases that
verify these namespaces appear in the decorations. In particular,
stashes and replace refs can have custom colors from the
color.decorate.<slot> config option.
While one test checks for a decoration from notes, it only applies to
the tip of refs/notes/commit (or its configured ref name). Notes form
their own kind of decoration instead. Modify the expected output for the
tests in t4013 that expect this note decoration. There are several
tests throughout the codebase that verify that --decorate-refs,
--decorate-refs-exclude, and log.excludeDecoration work as designed and
the tests continue to pass without intervention.
However, there are other refs that are less helpful to show as
decoration:
* Prefetch refs (refs/prefetch/)
* Rebase refs (refs/rebase-merge/ and refs/rebase-apply/)
* Bundle refs (refs/bundle/) [!]
[!] The bundle refs are part of a parallel series that bootstraps a repo
from a bundle file, storing the bundle's refs into the repo's
refs/bundle/ namespace.
In the case of prefetch refs, 96eaffebbf3d0 (maintenance: set
log.excludeDecoration durin prefetch, 2021-01-19) added logic to add
refs/prefetch/ to the log.excludeDecoration config option. Additional
feedback pointed out that having such a side-effect can be confusing and
perhaps not helpful to users. Instead, we should hide these ref
namespaces that are being used by Git for internal reasons but are not
helpful for the users to see.
The way to provide a seamless user experience without setting the config
is to modify the default decoration filters to match our expectation of
what refs the user actually wants to see.
In builtin/log.c, after parsing the --decorate-refs and
--decorate-refs-exclude options from the command-line, call
set_default_decoration_filter(). This method populates the exclusions
from log.excludeDecoration, then checks if the list of pattern
modifications are empty. If none are specified, then the default set is
restricted to the set of inclusions mentioned earlier (HEAD, branches,
etc.). A previous change introduced the ref_namespaces array, which
includes all of these currently-used namespaces. The 'decoration' value
is non-zero when that namespace is associated with a special coloring
and fits into the list of "expected" decorations as described above,
which makes the implementation of this filter very simple.
Note that the logic in ref_filter_match() in log-tree.c follows this
matching pattern:
1. If there are exclusion patterns and the ref matches one, then ignore
the decoration.
2. If there are inclusion patterns and the ref matches one, then
definitely include the decoration.
3. If there are config-based exclusions from log.excludeDecoration and
the ref matches one, then ignore the decoration.
With this logic in mind, we need to ensure that we do not populate our
new defaults if any of these filters are manually set. Specifically, if
a user runs
git -c log.excludeDecoration=HEAD log
then we expect the HEAD decoration to not appear. If we left the default
inclusions in the set, then HEAD would match that inclusion before
reaching the config-based exclusions.
A potential alternative would be to check the list of default inclusions
at the end, after the config-based exclusions. This would still create a
behavior change for some uses of --decorate-refs-exclude=<X>, and could
be overwritten somewhat with --decorate-refs=refs/ and
--decorate-refs=HEAD. However, it no longer becomes possible to include
refs outside of the defaults while also excluding some using
log.excludeDecoration.
Another alternative would be to exclude the known namespaces that are
not intended to be shown. This would reduce the visible effect of the
change for expert users who use their own custom ref namespaces. The
implementation change would be very simple to swap due to our use of
ref_namespaces:
int i;
struct string_list *exclude = decoration_filter->exclude_ref_pattern;
/*
* No command-line or config options were given, so
* populate with sensible defaults.
*/
for (i = 0; i < NAMESPACE__COUNT; i++) {
if (ref_namespaces[i].decoration)
continue;
string_list_append(exclude, ref_namespaces[i].ref);
}
The main downside of this approach is that we expect to add new hidden
namespaces in the future, and that means that Git versions will be less
stable in how they behave as those namespaces are added.
It is critical that we provide ways for expert users to disable this
behavior change via command-line options and config keys. These changes
will be implemented in a future change.
Add a test that checks that the defaults are not added when
--decorate-refs is specified. We verify this by showing that HEAD is not
included as it normally would. Also add a test that shows that the
default filter avoids the unwanted decorations from refs/prefetch,
refs/rebase-merge,
and refs/bundle.
Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-05 19:58:39 +02:00
|
|
|
+
|
|
|
|
|
If none of these options or config settings are given, then references are
|
|
|
|
|
used as decoration if they match `HEAD`, `refs/heads/`, `refs/remotes/`,
|
|
|
|
|
`refs/stash/`, or `refs/tags/`.
|
log: add option to choose which refs to decorate
When `log --decorate` is used, git will decorate commits with all
available refs. While in most cases this may give the desired effect,
under some conditions it can lead to excessively verbose output.
Introduce two command line options, `--decorate-refs=<pattern>` and
`--decorate-refs-exclude=<pattern>` to allow the user to select which
refs are used in decoration.
When "--decorate-refs=<pattern>" is given, only the refs that match the
pattern are used in decoration. The refs that match the pattern when
"--decorate-refs-exclude=<pattern>" is given, are never used in
decoration.
These options follow the same convention for mixing negative and
positive patterns across the system, assuming that the inclusive default
is to match all refs available.
(1) if there is no positive pattern given, pretend as if an
inclusive default positive pattern was given;
(2) for each candidate, reject it if it matches no positive
pattern, or if it matches any one of the negative patterns.
The rules for what is considered a match are slightly different from the
rules used elsewhere.
Commands like `log --glob` assume a trailing '/*' when glob chars are
not present in the pattern. This makes it difficult to specify a single
ref. On the other hand, commands like `describe --match --all` allow
specifying exact refs, but do not have the convenience of allowing
"shorthand refs" like 'refs/heads' or 'heads' to refer to
'refs/heads/*'.
The commands introduced in this patch consider a match if:
(a) the pattern contains globs chars,
and regular pattern matching returns a match.
(b) the pattern does not contain glob chars,
and ref '<pattern>' exists, or if ref exists under '<pattern>/'
This allows both behaviours (allowing single refs and shorthand refs)
yet remaining compatible with existent commands.
Helped-by: Kevin Daudt <me@ikke.info>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Rafael Ascensão <rafa.almas@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-21 22:33:41 +01:00
|
|
|
|
2022-08-05 19:58:40 +02:00
|
|
|
--clear-decorations::
|
|
|
|
|
When specified, this option clears all previous `--decorate-refs`
|
|
|
|
|
or `--decorate-refs-exclude` options and relaxes the default
|
2022-08-05 19:58:41 +02:00
|
|
|
decoration filter to include all references. This option is
|
|
|
|
|
assumed if the config value `log.initialDecorationSet` is set to
|
|
|
|
|
`all`.
|
2022-08-05 19:58:40 +02:00
|
|
|
|
2008-11-10 10:58:15 +01:00
|
|
|
--source::
|
|
|
|
|
Print out the ref name given on the command line by which each
|
|
|
|
|
commit was reached.
|
|
|
|
|
|
2020-03-16 21:30:38 +01:00
|
|
|
--[no-]mailmap::
|
2019-07-15 14:41:05 +02:00
|
|
|
--[no-]use-mailmap::
|
2013-01-05 22:26:43 +01:00
|
|
|
Use mailmap file to map author and committer names and email
|
2013-11-13 07:21:49 +01:00
|
|
|
addresses to canonical real names and email addresses. See
|
2013-01-05 22:26:43 +01:00
|
|
|
linkgit:git-shortlog[1].
|
|
|
|
|
|
2007-06-16 21:03:38 +02:00
|
|
|
--full-diff::
|
2013-11-13 07:21:49 +01:00
|
|
|
Without this flag, `git log -p <path>...` shows commits that
|
2007-06-16 21:03:38 +02:00
|
|
|
touch the specified paths, and diffs about the same specified
|
|
|
|
|
paths. With this, the full diff is shown for commits that touch
|
2008-07-30 11:33:43 +02:00
|
|
|
the specified paths; this means that "<path>..." limits only
|
2007-06-16 21:03:38 +02:00
|
|
|
commits, and doesn't limit diff for those commits.
|
2010-08-08 17:31:34 +02:00
|
|
|
+
|
|
|
|
|
Note that this affects all diff-based output types, e.g. those
|
2013-11-13 07:21:49 +01:00
|
|
|
produced by `--stat`, etc.
|
2007-06-16 21:03:38 +02:00
|
|
|
|
2007-07-20 20:15:13 +02:00
|
|
|
--log-size::
|
2013-11-13 07:21:48 +01:00
|
|
|
Include a line ``log size <number>'' in the output for each commit,
|
|
|
|
|
where <number> is the length of that commit's message in bytes.
|
|
|
|
|
Intended to speed up tools that read log messages from `git log`
|
|
|
|
|
output by allowing them to allocate space in advance.
|
2007-07-20 20:15:13 +02:00
|
|
|
|
2020-11-01 18:28:40 +01:00
|
|
|
include::line-range-options.txt[]
|
Implement line-history search (git log -L)
This is a rewrite of much of Bo's work, mainly in an effort to split
it into smaller, easier to understand routines.
The algorithm is built around the struct range_set, which encodes a
series of line ranges as intervals [a,b). This is used in two
contexts:
* A set of lines we are tracking (which will change as we dig through
history).
* To encode diffs, as pairs of ranges.
The main routine is range_set_map_across_diff(). It processes the
diff between a commit C and some parent P. It determines which diff
hunks are relevant to the ranges tracked in C, and computes the new
ranges for P.
The algorithm is then simply to process history in topological order
from newest to oldest, computing ranges and (partial) diffs. At
branch points, we need to merge the ranges we are watching. We will
find that many commits do not affect the chosen ranges, and mark them
TREESAME (in addition to those already filtered by pathspec limiting).
Another pass of history simplification then gets rid of such commits.
This is wired as an extra filtering pass in the log machinery. This
currently only reduces code duplication, but should allow for other
simplifications and options to be used.
Finally, we hook a diff printer into the output chain. Ideally we
would wire directly into the diff logic, to optionally use features
like word diff. However, that will require some major reworking of
the diff chain, so we completely replace the output with our own diff
for now.
As this was a GSoC project, and has quite some history by now, many
people have helped. In no particular order, thanks go to
Jakub Narebski <jnareb@gmail.com>
Jens Lehmann <Jens.Lehmann@web.de>
Jonathan Nieder <jrnieder@gmail.com>
Junio C Hamano <gitster@pobox.com>
Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Will Palmer <wmpalmer@gmail.com>
Apologies to everyone I forgot.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-28 17:47:32 +01:00
|
|
|
|
2021-11-06 19:48:52 +01:00
|
|
|
<revision-range>::
|
2013-04-22 07:30:28 +02:00
|
|
|
Show only commits in the specified revision range. When no
|
2021-11-06 19:48:52 +01:00
|
|
|
<revision-range> is specified, it defaults to `HEAD` (i.e. the
|
2013-04-22 07:30:28 +02:00
|
|
|
whole history leading to the current commit). `origin..HEAD`
|
|
|
|
|
specifies all the commits reachable from the current commit
|
|
|
|
|
(i.e. `HEAD`), but not from `origin`. For a complete list of
|
2021-11-06 19:48:52 +01:00
|
|
|
ways to spell <revision-range>, see the 'Specifying Ranges'
|
2013-04-22 07:30:28 +02:00
|
|
|
section of linkgit:gitrevisions[7].
|
2013-04-22 07:30:27 +02:00
|
|
|
|
2018-04-17 21:15:27 +02:00
|
|
|
[--] <path>...::
|
2011-08-30 11:21:07 +02:00
|
|
|
Show only commits that are enough to explain how the files
|
2013-11-13 07:21:49 +01:00
|
|
|
that match the specified paths came to be. See 'History
|
|
|
|
|
Simplification' below for details and other simplification
|
2011-08-30 11:21:07 +02:00
|
|
|
modes.
|
|
|
|
|
+
|
git-[short]log.txt: unify quoted standalone --
In git-log.txt, we have an instance of \--, which is known to sometimes
render badly. This one is even worse than normal though, since ``\-- ''
(with or without that trailing space) appears to be entirely broken,
both in HTML and manpages, both with AsciiDoc (version 8.6.9) and
Asciidoctor (version 1.5.4).
Further down in git-log.txt we have a ``--'', which renders good. In
git-shortlog.txt, we use "\-- " (including the quotes and the space),
which happens to look fairly good. I failed to find any other similar
instances. So all in all, we quote a double-dash in three different
places and do it differently each time, with various degrees of success.
Switch all of these to `--`. This sets the double-dash in monospace and
matches what we usually do with example command line usages and options.
Note that we drop the trailing space as well, since `-- ` does not
render well. These should still be clear enough since just a few lines
above each instance, the space is clearly visible in a longer context.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
2018-04-17 21:15:28 +02:00
|
|
|
Paths may need to be prefixed with `--` to separate them from
|
2013-04-22 07:30:29 +02:00
|
|
|
options or the revision range, when confusion arises.
|
2006-04-14 21:59:09 +02:00
|
|
|
|
2011-03-08 09:31:26 +01:00
|
|
|
include::rev-list-options.txt[]
|
|
|
|
|
|
|
|
|
|
include::pretty-formats.txt[]
|
|
|
|
|
|
2020-07-29 22:11:16 +02:00
|
|
|
DIFF FORMATTING
|
|
|
|
|
---------------
|
|
|
|
|
|
|
|
|
|
By default, `git log` does not generate any diff output. The options
|
|
|
|
|
below can be used to show the changes made by each commit.
|
|
|
|
|
|
2020-12-21 16:19:56 +01:00
|
|
|
Note that unless one of `--diff-merges` variants (including short
|
|
|
|
|
`-m`, `-c`, and `--cc` options) is explicitly given, merge commits
|
|
|
|
|
will not show a diff, even if a diff format like `--patch` is
|
|
|
|
|
selected, nor will they match search options like `-S`. The exception
|
|
|
|
|
is when `--first-parent` is in use, in which case `first-parent` is
|
|
|
|
|
the default format.
|
2020-08-06 00:08:31 +02:00
|
|
|
|
2010-07-08 04:14:31 +02:00
|
|
|
:git-log: 1
|
2020-12-21 16:19:59 +01:00
|
|
|
:diff-merges-default: `off`
|
2010-07-08 04:14:31 +02:00
|
|
|
include::diff-options.txt[]
|
2007-05-14 01:25:45 +02:00
|
|
|
|
2007-11-01 15:57:40 +01:00
|
|
|
include::diff-generate-patch.txt[]
|
2007-05-14 01:25:45 +02:00
|
|
|
|
2013-07-16 10:05:40 +02:00
|
|
|
EXAMPLES
|
2005-10-31 05:05:32 +01:00
|
|
|
--------
|
docs: put listed example commands in backticks
Many examples of git command invocation are given in asciidoc listing
blocks, which makes them monospaced and avoids further interpretation of
special characters. Some manpages make a list of examples, like:
git foo::
Run git foo.
git foo -q::
Use the "-q" option.
to quickly show many variants. However, they can sometimes be hard to
read, because they are shown in a proportional-width font (so, for
example, seeing the difference between "-- foo" and "--foo" can be
difficult).
This patch puts all such examples into backticks, which gives the
equivalent formatting to a listing block (i.e., monospaced and without
character interpretation).
As a bonus, this also fixes an example in the git-push manpage, in which
"git push origin :::" was accidentally considered a newly-indented list,
and not a list item with "git push origin :" in it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 04:13:29 +02:00
|
|
|
`git log --no-merges`::
|
2005-10-31 05:05:32 +01:00
|
|
|
|
|
|
|
|
Show the whole commit history, but skip any merges
|
|
|
|
|
|
docs: put listed example commands in backticks
Many examples of git command invocation are given in asciidoc listing
blocks, which makes them monospaced and avoids further interpretation of
special characters. Some manpages make a list of examples, like:
git foo::
Run git foo.
git foo -q::
Use the "-q" option.
to quickly show many variants. However, they can sometimes be hard to
read, because they are shown in a proportional-width font (so, for
example, seeing the difference between "-- foo" and "--foo" can be
difficult).
This patch puts all such examples into backticks, which gives the
equivalent formatting to a listing block (i.e., monospaced and without
character interpretation).
As a bonus, this also fixes an example in the git-push manpage, in which
"git push origin :::" was accidentally considered a newly-indented list,
and not a list item with "git push origin :" in it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 04:13:29 +02:00
|
|
|
`git log v2.6.12.. include/scsi drivers/scsi`::
|
2005-10-31 05:05:32 +01:00
|
|
|
|
|
|
|
|
Show all commits since version 'v2.6.12' that changed any file
|
2013-11-13 07:21:49 +01:00
|
|
|
in the `include/scsi` or `drivers/scsi` subdirectories
|
2005-10-31 05:05:32 +01:00
|
|
|
|
docs: stop using asciidoc no-inline-literal
In asciidoc 7, backticks like `foo` produced a typographic
effect, but did not otherwise affect the syntax. In asciidoc
8, backticks introduce an "inline literal" inside which markup
is not interpreted. To keep compatibility with existing
documents, asciidoc 8 has a "no-inline-literal" attribute to
keep the old behavior. We enabled this so that the
documentation could be built on either version.
It has been several years now, and asciidoc 7 is no longer
in wide use. We can now decide whether or not we want
inline literals on their own merits, which are:
1. The source is much easier to read when the literal
contains punctuation. You can use `master~1` instead
of `master{tilde}1`.
2. They are less error-prone. Because of point (1), we
tend to make mistakes and forget the extra layer of
quoting.
This patch removes the no-inline-literal attribute from the
Makefile and converts every use of backticks in the
documentation to an inline literal (they must be cleaned up,
or the example above would literally show "{tilde}" in the
output).
Problematic sites were found by grepping for '`.*[{\\]' and
examined and fixed manually. The results were then verified
by comparing the output of "html2text" on the set of
generated html pages. Doing so revealed that in addition to
making the source more readable, this patch fixes several
formatting bugs:
- HTML rendering used the ellipsis character instead of
literal "..." in code examples (like "git log A...B")
- some code examples used the right-arrow character
instead of '->' because they failed to quote
- api-config.txt did not quote tilde, and the resulting
HTML contained a bogus snippet like:
<tt><sub></tt> foo <tt></sub>bar</tt>
which caused some parsers to choke and omit whole
sections of the page.
- git-commit.txt confused ``foo`` (backticks inside a
literal) with ``foo'' (matched double-quotes)
- mentions of `A U Thor <author@example.com>` used to
erroneously auto-generate a mailto footnote for
author@example.com
- the description of --word-diff=plain incorrectly showed
the output as "[-removed-] and {added}", not "{+added+}".
- using "prime" notation like:
commit `C` and its replacement `C'`
confused asciidoc into thinking that everything between
the first backtick and the final apostrophe were meant
to be inside matched quotes
- asciidoc got confused by the escaping of some of our
asterisks. In particular,
`credential.\*` and `credential.<url>.\*`
properly escaped the asterisk in the first case, but
literally passed through the backslash in the second
case.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-26 10:51:57 +02:00
|
|
|
`git log --since="2 weeks ago" -- gitk`::
|
2005-10-31 05:05:32 +01:00
|
|
|
|
|
|
|
|
Show the changes during the last two weeks to the file 'gitk'.
|
git-[short]log.txt: unify quoted standalone --
In git-log.txt, we have an instance of \--, which is known to sometimes
render badly. This one is even worse than normal though, since ``\-- ''
(with or without that trailing space) appears to be entirely broken,
both in HTML and manpages, both with AsciiDoc (version 8.6.9) and
Asciidoctor (version 1.5.4).
Further down in git-log.txt we have a ``--'', which renders good. In
git-shortlog.txt, we use "\-- " (including the quotes and the space),
which happens to look fairly good. I failed to find any other similar
instances. So all in all, we quote a double-dash in three different
places and do it differently each time, with various degrees of success.
Switch all of these to `--`. This sets the double-dash in monospace and
matches what we usually do with example command line usages and options.
Note that we drop the trailing space as well, since `-- ` does not
render well. These should still be clear enough since just a few lines
above each instance, the space is clearly visible in a longer context.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
2018-04-17 21:15:28 +02:00
|
|
|
The `--` is necessary to avoid confusion with the *branch* named
|
2005-10-31 05:05:32 +01:00
|
|
|
'gitk'
|
|
|
|
|
|
docs: put listed example commands in backticks
Many examples of git command invocation are given in asciidoc listing
blocks, which makes them monospaced and avoids further interpretation of
special characters. Some manpages make a list of examples, like:
git foo::
Run git foo.
git foo -q::
Use the "-q" option.
to quickly show many variants. However, they can sometimes be hard to
read, because they are shown in a proportional-width font (so, for
example, seeing the difference between "-- foo" and "--foo" can be
difficult).
This patch puts all such examples into backticks, which gives the
equivalent formatting to a listing block (i.e., monospaced and without
character interpretation).
As a bonus, this also fixes an example in the git-push manpage, in which
"git push origin :::" was accidentally considered a newly-indented list,
and not a list item with "git push origin :" in it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 04:13:29 +02:00
|
|
|
`git log --name-status release..test`::
|
2006-04-14 21:59:09 +02:00
|
|
|
|
|
|
|
|
Show the commits that are in the "test" branch but not yet
|
|
|
|
|
in the "release" branch, along with the list of paths
|
|
|
|
|
each commit modifies.
|
2005-10-31 05:05:32 +01:00
|
|
|
|
2013-06-18 19:44:58 +02:00
|
|
|
`git log --follow builtin/rev-list.c`::
|
2007-07-12 16:52:30 +02:00
|
|
|
|
2013-11-13 07:21:49 +01:00
|
|
|
Shows the commits that changed `builtin/rev-list.c`, including
|
2007-07-12 16:52:30 +02:00
|
|
|
those commits that occurred before the file was given its
|
|
|
|
|
present name.
|
|
|
|
|
|
docs: put listed example commands in backticks
Many examples of git command invocation are given in asciidoc listing
blocks, which makes them monospaced and avoids further interpretation of
special characters. Some manpages make a list of examples, like:
git foo::
Run git foo.
git foo -q::
Use the "-q" option.
to quickly show many variants. However, they can sometimes be hard to
read, because they are shown in a proportional-width font (so, for
example, seeing the difference between "-- foo" and "--foo" can be
difficult).
This patch puts all such examples into backticks, which gives the
equivalent formatting to a listing block (i.e., monospaced and without
character interpretation).
As a bonus, this also fixes an example in the git-push manpage, in which
"git push origin :::" was accidentally considered a newly-indented list,
and not a list item with "git push origin :" in it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 04:13:29 +02:00
|
|
|
`git log --branches --not --remotes=origin`::
|
2010-01-20 10:48:25 +01:00
|
|
|
|
|
|
|
|
Shows all commits that are in any of local branches but not in
|
2010-11-02 16:31:20 +01:00
|
|
|
any of remote-tracking branches for 'origin' (what you have that
|
2010-01-20 10:48:25 +01:00
|
|
|
origin doesn't).
|
|
|
|
|
|
docs: put listed example commands in backticks
Many examples of git command invocation are given in asciidoc listing
blocks, which makes them monospaced and avoids further interpretation of
special characters. Some manpages make a list of examples, like:
git foo::
Run git foo.
git foo -q::
Use the "-q" option.
to quickly show many variants. However, they can sometimes be hard to
read, because they are shown in a proportional-width font (so, for
example, seeing the difference between "-- foo" and "--foo" can be
difficult).
This patch puts all such examples into backticks, which gives the
equivalent formatting to a listing block (i.e., monospaced and without
character interpretation).
As a bonus, this also fixes an example in the git-push manpage, in which
"git push origin :::" was accidentally considered a newly-indented list,
and not a list item with "git push origin :" in it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 04:13:29 +02:00
|
|
|
`git log master --not --remotes=*/master`::
|
2010-01-20 10:48:25 +01:00
|
|
|
|
|
|
|
|
Shows all commits that are in local master but not in any remote
|
|
|
|
|
repository master branches.
|
|
|
|
|
|
docs: put listed example commands in backticks
Many examples of git command invocation are given in asciidoc listing
blocks, which makes them monospaced and avoids further interpretation of
special characters. Some manpages make a list of examples, like:
git foo::
Run git foo.
git foo -q::
Use the "-q" option.
to quickly show many variants. However, they can sometimes be hard to
read, because they are shown in a proportional-width font (so, for
example, seeing the difference between "-- foo" and "--foo" can be
difficult).
This patch puts all such examples into backticks, which gives the
equivalent formatting to a listing block (i.e., monospaced and without
character interpretation).
As a bonus, this also fixes an example in the git-push manpage, in which
"git push origin :::" was accidentally considered a newly-indented list,
and not a list item with "git push origin :" in it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 04:13:29 +02:00
|
|
|
`git log -p -m --first-parent`::
|
2010-02-10 02:11:49 +01:00
|
|
|
|
|
|
|
|
Shows the history including change diffs, but only from the
|
2013-11-13 07:21:49 +01:00
|
|
|
``main branch'' perspective, skipping commits that come from merged
|
2010-02-10 02:11:49 +01:00
|
|
|
branches, and showing full diffs of changes introduced by the merges.
|
|
|
|
|
This makes sense only when following a strict policy of merging all
|
|
|
|
|
topic branches when staying on a single integration branch.
|
|
|
|
|
|
2013-07-16 02:10:36 +02:00
|
|
|
`git log -L '/int main/',/^}/:main.c`::
|
Implement line-history search (git log -L)
This is a rewrite of much of Bo's work, mainly in an effort to split
it into smaller, easier to understand routines.
The algorithm is built around the struct range_set, which encodes a
series of line ranges as intervals [a,b). This is used in two
contexts:
* A set of lines we are tracking (which will change as we dig through
history).
* To encode diffs, as pairs of ranges.
The main routine is range_set_map_across_diff(). It processes the
diff between a commit C and some parent P. It determines which diff
hunks are relevant to the ranges tracked in C, and computes the new
ranges for P.
The algorithm is then simply to process history in topological order
from newest to oldest, computing ranges and (partial) diffs. At
branch points, we need to merge the ranges we are watching. We will
find that many commits do not affect the chosen ranges, and mark them
TREESAME (in addition to those already filtered by pathspec limiting).
Another pass of history simplification then gets rid of such commits.
This is wired as an extra filtering pass in the log machinery. This
currently only reduces code duplication, but should allow for other
simplifications and options to be used.
Finally, we hook a diff printer into the output chain. Ideally we
would wire directly into the diff logic, to optionally use features
like word diff. However, that will require some major reworking of
the diff chain, so we completely replace the output with our own diff
for now.
As this was a GSoC project, and has quite some history by now, many
people have helped. In no particular order, thanks go to
Jakub Narebski <jnareb@gmail.com>
Jens Lehmann <Jens.Lehmann@web.de>
Jonathan Nieder <jrnieder@gmail.com>
Junio C Hamano <gitster@pobox.com>
Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Will Palmer <wmpalmer@gmail.com>
Apologies to everyone I forgot.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-28 17:47:32 +01:00
|
|
|
|
2013-11-13 07:21:49 +01:00
|
|
|
Shows how the function `main()` in the file `main.c` evolved
|
Implement line-history search (git log -L)
This is a rewrite of much of Bo's work, mainly in an effort to split
it into smaller, easier to understand routines.
The algorithm is built around the struct range_set, which encodes a
series of line ranges as intervals [a,b). This is used in two
contexts:
* A set of lines we are tracking (which will change as we dig through
history).
* To encode diffs, as pairs of ranges.
The main routine is range_set_map_across_diff(). It processes the
diff between a commit C and some parent P. It determines which diff
hunks are relevant to the ranges tracked in C, and computes the new
ranges for P.
The algorithm is then simply to process history in topological order
from newest to oldest, computing ranges and (partial) diffs. At
branch points, we need to merge the ranges we are watching. We will
find that many commits do not affect the chosen ranges, and mark them
TREESAME (in addition to those already filtered by pathspec limiting).
Another pass of history simplification then gets rid of such commits.
This is wired as an extra filtering pass in the log machinery. This
currently only reduces code duplication, but should allow for other
simplifications and options to be used.
Finally, we hook a diff printer into the output chain. Ideally we
would wire directly into the diff logic, to optionally use features
like word diff. However, that will require some major reworking of
the diff chain, so we completely replace the output with our own diff
for now.
As this was a GSoC project, and has quite some history by now, many
people have helped. In no particular order, thanks go to
Jakub Narebski <jnareb@gmail.com>
Jens Lehmann <Jens.Lehmann@web.de>
Jonathan Nieder <jrnieder@gmail.com>
Junio C Hamano <gitster@pobox.com>
Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Will Palmer <wmpalmer@gmail.com>
Apologies to everyone I forgot.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-28 17:47:32 +01:00
|
|
|
over time.
|
|
|
|
|
|
2012-09-06 16:28:03 +02:00
|
|
|
`git log -3`::
|
2013-11-13 07:21:49 +01:00
|
|
|
|
2012-09-06 16:28:03 +02:00
|
|
|
Limits the number of commits to show to 3.
|
2010-02-10 02:11:49 +01:00
|
|
|
|
2013-07-16 10:05:40 +02:00
|
|
|
DISCUSSION
|
2006-12-30 11:22:38 +01:00
|
|
|
----------
|
|
|
|
|
|
|
|
|
|
include::i18n.txt[]
|
|
|
|
|
|
2013-07-16 10:05:40 +02:00
|
|
|
CONFIGURATION
|
2010-05-09 05:30:41 +02:00
|
|
|
-------------
|
|
|
|
|
|
|
|
|
|
See linkgit:git-config[1] for core variables and linkgit:git-diff[1]
|
|
|
|
|
for settings related to diff generation.
|
|
|
|
|
|
|
|
|
|
format.pretty::
|
2013-11-13 07:21:49 +01:00
|
|
|
Default for the `--format` option. (See 'Pretty Formats' above.)
|
|
|
|
|
Defaults to `medium`.
|
2010-05-09 05:30:41 +02:00
|
|
|
|
|
|
|
|
i18n.logOutputEncoding::
|
2013-11-13 07:21:49 +01:00
|
|
|
Encoding to use when displaying logs. (See 'Discussion' above.)
|
|
|
|
|
Defaults to the value of `i18n.commitEncoding` if set, and UTF-8
|
2010-05-09 05:30:41 +02:00
|
|
|
otherwise.
|
|
|
|
|
|
2022-09-07 10:27:01 +02:00
|
|
|
include::includes/cmd-config-section-rest.txt[]
|
|
|
|
|
|
2022-09-07 10:27:03 +02:00
|
|
|
include::config/log.txt[]
|
|
|
|
|
|
2022-09-07 10:27:01 +02:00
|
|
|
include::config/notes.txt[]
|
2006-12-30 11:22:38 +01:00
|
|
|
|
2005-08-15 02:24:36 +02:00
|
|
|
GIT
|
|
|
|
|
---
|
2008-06-06 09:07:32 +02:00
|
|
|
Part of the linkgit:git[1] suite
|