2018-04-02 22:34:18 +02:00
|
|
|
git-commit-graph(1)
|
|
|
|
===================
|
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
2018-09-27 21:12:22 +02:00
|
|
|
git-commit-graph - Write and verify Git commit-graph files
|
2018-04-02 22:34:18 +02:00
|
|
|
|
2018-04-02 22:34:20 +02:00
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
|
|
|
[verse]
|
2019-08-26 18:29:58 +02:00
|
|
|
'git commit-graph verify' [--object-dir <dir>] [--shallow] [--[no-]progress]
|
|
|
|
'git commit-graph write' <options> [--object-dir <dir>] [--[no-]progress]
|
2018-04-02 22:34:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
|
|
|
|
2018-09-27 21:12:22 +02:00
|
|
|
Manage the serialized commit-graph file.
|
2018-04-02 22:34:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
OPTIONS
|
|
|
|
-------
|
|
|
|
--object-dir::
|
2018-09-27 21:12:22 +02:00
|
|
|
Use given directory for the location of packfiles and commit-graph
|
2018-04-02 22:34:20 +02:00
|
|
|
file. This parameter exists to specify the location of an alternate
|
2018-09-27 21:12:20 +02:00
|
|
|
that only has the objects directory, not a full `.git` directory. The
|
2019-06-18 20:14:32 +02:00
|
|
|
commit-graph file is expected to be in the `<dir>/info` directory and
|
2020-02-04 06:51:50 +01:00
|
|
|
the packfiles are expected to be in `<dir>/pack`. If the directory
|
|
|
|
could not be made into an absolute path, or does not match any known
|
|
|
|
object directory, `git commit-graph ...` will exit with non-zero
|
|
|
|
status.
|
2018-04-02 22:34:20 +02:00
|
|
|
|
2019-08-26 18:29:58 +02:00
|
|
|
--[no-]progress::
|
|
|
|
Turn progress on/off explicitly. If neither is specified, progress is
|
|
|
|
shown if standard error is connected to a terminal.
|
2018-04-02 22:34:20 +02:00
|
|
|
|
|
|
|
COMMANDS
|
|
|
|
--------
|
|
|
|
'write'::
|
|
|
|
|
2020-10-09 22:53:52 +02:00
|
|
|
Write a commit-graph file based on the commits found in packfiles. If
|
|
|
|
the config option `core.commitGraph` is disabled, then this command will
|
|
|
|
output a warning, then return success without writing a commit-graph file.
|
2018-04-10 14:56:06 +02:00
|
|
|
+
|
|
|
|
With the `--stdin-packs` option, generate the new commit graph by
|
2018-04-10 14:56:07 +02:00
|
|
|
walking objects only in the specified pack-indexes. (Cannot be combined
|
2018-06-27 15:24:45 +02:00
|
|
|
with `--stdin-commits` or `--reachable`.)
|
2018-04-10 14:56:07 +02:00
|
|
|
+
|
|
|
|
With the `--stdin-commits` option, generate the new commit graph by
|
|
|
|
walking commits starting at the commits specified in stdin as a list
|
commit-graph: drop COMMIT_GRAPH_WRITE_CHECK_OIDS flag
Since 7c5c9b9c57 (commit-graph: error out on invalid commit oids in
'write --stdin-commits', 2019-08-05), the commit-graph builtin dies on
receiving non-commit OIDs as input to '--stdin-commits'.
This behavior can be cumbersome to work around in, say, the case of
piping 'git for-each-ref' to 'git commit-graph write --stdin-commits' if
the caller does not want to cull out non-commits themselves. In this
situation, it would be ideal if 'git commit-graph write' wrote the graph
containing the inputs that did pertain to commits, and silently ignored
the remainder of the input.
Some options have been proposed to the effect of '--[no-]check-oids'
which would allow callers to have the commit-graph builtin do just that.
After some discussion, it is difficult to imagine a caller who wouldn't
want to pass '--no-check-oids', suggesting that we should get rid of the
behavior of complaining about non-commit inputs altogether.
If callers do wish to retain this behavior, they can easily work around
this change by doing the following:
git for-each-ref --format='%(objectname) %(objecttype) %(*objecttype)' |
awk '
!/commit/ { print "not-a-commit:"$1 }
/commit/ { print $1 }
' |
git commit-graph write --stdin-commits
To make it so that valid OIDs that refer to non-existent objects are
indeed an error after loosening the error handling, perform an extra
lookup to make sure that object indeed exists before sending it to the
commit-graph internals.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-13 23:59:55 +02:00
|
|
|
of OIDs in hex, one OID per line. OIDs that resolve to non-commits
|
|
|
|
(either directly, or by peeling tags) are silently ignored. OIDs that
|
|
|
|
are malformed, or do not exist generate an error. (Cannot be combined
|
|
|
|
with `--stdin-packs` or `--reachable`.)
|
2018-06-27 15:24:45 +02:00
|
|
|
+
|
|
|
|
With the `--reachable` option, generate the new commit graph by walking
|
|
|
|
commits starting at all refs. (Cannot be combined with `--stdin-commits`
|
|
|
|
or `--stdin-packs`.)
|
2018-04-10 14:56:08 +02:00
|
|
|
+
|
|
|
|
With the `--append` option, include all commits that are present in the
|
|
|
|
existing commit-graph file.
|
2019-06-18 20:14:32 +02:00
|
|
|
+
|
2020-04-06 18:59:51 +02:00
|
|
|
With the `--changed-paths` option, compute and write information about the
|
2020-05-17 20:52:18 +02:00
|
|
|
paths changed between a commit and its first parent. This operation can
|
2020-04-06 18:59:51 +02:00
|
|
|
take a while on large repositories. It provides significant performance gains
|
2020-07-01 15:27:24 +02:00
|
|
|
for getting history of a directory or a file with `git log -- <path>`. If
|
|
|
|
this option is given, future commit-graph writes will automatically assume
|
|
|
|
that this option was intended. Use `--no-changed-paths` to stop storing this
|
|
|
|
data.
|
2020-04-06 18:59:51 +02:00
|
|
|
+
|
2020-09-18 15:27:27 +02:00
|
|
|
With the `--max-new-filters=<n>` option, generate at most `n` new Bloom
|
|
|
|
filters (if `--changed-paths` is specified). If `n` is `-1`, no limit is
|
|
|
|
enforced. Only commits present in the new layer count against this
|
|
|
|
limit. To retroactively compute Bloom filters over earlier layers, it is
|
2020-09-18 04:59:57 +02:00
|
|
|
advised to use `--split=replace`. Overrides the `commitGraph.maxNewFilters`
|
|
|
|
configuration.
|
2020-09-18 15:27:27 +02:00
|
|
|
+
|
2020-04-14 06:04:08 +02:00
|
|
|
With the `--split[=<strategy>]` option, write the commit-graph as a
|
|
|
|
chain of multiple commit-graph files stored in
|
|
|
|
`<dir>/info/commit-graphs`. Commit-graph layers are merged based on the
|
|
|
|
strategy and other splitting options. The new commits not already in the
|
|
|
|
commit-graph are added in a new "tip" file. This file is merged with the
|
|
|
|
existing file if the following merge conditions are met:
|
2020-05-17 20:52:19 +02:00
|
|
|
+
|
builtin/commit-graph.c: introduce split strategy 'no-merge'
In the previous commit, we laid the groundwork for supporting different
splitting strategies. In this commit, we introduce the first splitting
strategy: 'no-merge'.
Passing '--split=no-merge' is useful for callers which wish to write a
new incremental commit-graph, but do not want to spend effort condensing
the incremental chain [1]. Previously, this was possible by passing
'--size-multiple=0', but this no longer the case following 63020f175f
(commit-graph: prefer default size_mult when given zero, 2020-01-02).
When '--split=no-merge' is given, the commit-graph machinery will never
condense an existing chain, and it will always write a new incremental.
[1]: This might occur when, for example, a server administrator running
some program after each push may want to ensure that each job runs
proportional in time to the size of the push, and does not "jump" when
the commit-graph machinery decides to trigger a merge.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-14 06:04:12 +02:00
|
|
|
* If `--split=no-merge` is specified, a merge is never performed, and
|
builtin/commit-graph.c: introduce split strategy 'replace'
When using split commit-graphs, it is sometimes useful to completely
replace the commit-graph chain with a new base.
For example, consider a scenario in which a repository builds a new
commit-graph incremental for each push. Occasionally (say, after some
fixed number of pushes), they may wish to rebuild the commit-graph chain
with all reachable commits.
They can do so with
$ git commit-graph write --reachable
but this removes the chain entirely and replaces it with a single
commit-graph in 'objects/info/commit-graph'. Unfortunately, this means
that the next push will have to move this commit-graph into the first
layer of a new chain, and then write its new commits on top.
Avoid such copying entirely by allowing the caller to specify that they
wish to replace the entirety of their commit-graph chain, while also
specifying that the new commit-graph should become the basis of a fresh,
length-one chain.
This addresses the above situation by making it possible for the caller
to instead write:
$ git commit-graph write --reachable --split=replace
which writes a new length-one chain to 'objects/info/commit-graphs',
making the commit-graph incremental generated by the subsequent push
relatively cheap by avoiding the aforementioned copy.
In order to do this, remove an assumption in 'write_commit_graph_file'
that chains are always at least two incrementals long.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-14 06:04:17 +02:00
|
|
|
the remaining options are ignored. `--split=replace` overwrites the
|
|
|
|
existing chain with a new one. A bare `--split` defers to the remaining
|
|
|
|
options. (Note that merging a chain of commit graphs replaces the
|
|
|
|
existing chain with a length-1 chain where the first and only
|
builtin/commit-graph.c: introduce split strategy 'no-merge'
In the previous commit, we laid the groundwork for supporting different
splitting strategies. In this commit, we introduce the first splitting
strategy: 'no-merge'.
Passing '--split=no-merge' is useful for callers which wish to write a
new incremental commit-graph, but do not want to spend effort condensing
the incremental chain [1]. Previously, this was possible by passing
'--size-multiple=0', but this no longer the case following 63020f175f
(commit-graph: prefer default size_mult when given zero, 2020-01-02).
When '--split=no-merge' is given, the commit-graph machinery will never
condense an existing chain, and it will always write a new incremental.
[1]: This might occur when, for example, a server administrator running
some program after each push may want to ensure that each job runs
proportional in time to the size of the push, and does not "jump" when
the commit-graph machinery decides to trigger a merge.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-14 06:04:12 +02:00
|
|
|
incremental holds the entire graph).
|
2019-06-18 20:14:32 +02:00
|
|
|
+
|
|
|
|
* If `--size-multiple=<X>` is not specified, let `X` equal 2. If the new
|
|
|
|
tip file would have `N` commits and the previous tip has `M` commits and
|
|
|
|
`X` times `N` is greater than `M`, instead merge the two files into a
|
|
|
|
single file.
|
|
|
|
+
|
|
|
|
* If `--max-commits=<M>` is specified with `M` a positive integer, and the
|
|
|
|
new tip file would have more than `M` commits, then instead merge the new
|
|
|
|
tip with the previous tip.
|
|
|
|
+
|
|
|
|
Finally, if `--expire-time=<datetime>` is not specified, let `datetime`
|
|
|
|
be the current time. After writing the split commit-graph, delete all
|
|
|
|
unused commit-graph whose modified times are older than `datetime`.
|
2018-04-02 22:34:20 +02:00
|
|
|
|
2018-06-27 15:24:32 +02:00
|
|
|
'verify'::
|
|
|
|
|
|
|
|
Read the commit-graph file and verify its contents against the object
|
|
|
|
database. Used to check for corrupted data.
|
2019-06-18 20:14:32 +02:00
|
|
|
+
|
|
|
|
With the `--shallow` option, only check the tip commit-graph file in
|
|
|
|
a chain of split commit-graphs.
|
2018-06-27 15:24:32 +02:00
|
|
|
|
2018-04-02 22:34:20 +02:00
|
|
|
|
|
|
|
EXAMPLES
|
|
|
|
--------
|
|
|
|
|
2018-09-27 21:12:22 +02:00
|
|
|
* Write a commit-graph file for the packed commits in your local `.git`
|
2018-09-27 21:12:20 +02:00
|
|
|
directory.
|
2018-04-02 22:34:20 +02:00
|
|
|
+
|
|
|
|
------------------------------------------------
|
|
|
|
$ git commit-graph write
|
|
|
|
------------------------------------------------
|
|
|
|
|
2018-09-27 21:12:21 +02:00
|
|
|
* Write a commit-graph file, extending the current commit-graph file
|
|
|
|
using commits in `<pack-index>`.
|
2018-04-10 14:56:06 +02:00
|
|
|
+
|
|
|
|
------------------------------------------------
|
|
|
|
$ echo <pack-index> | git commit-graph write --stdin-packs
|
|
|
|
------------------------------------------------
|
|
|
|
|
2018-09-27 21:12:21 +02:00
|
|
|
* Write a commit-graph file containing all reachable commits.
|
2018-04-10 14:56:07 +02:00
|
|
|
+
|
|
|
|
------------------------------------------------
|
|
|
|
$ git show-ref -s | git commit-graph write --stdin-commits
|
|
|
|
------------------------------------------------
|
|
|
|
|
2018-09-27 21:12:21 +02:00
|
|
|
* Write a commit-graph file containing all commits in the current
|
2018-09-27 21:12:20 +02:00
|
|
|
commit-graph file along with those reachable from `HEAD`.
|
2018-04-10 14:56:08 +02:00
|
|
|
+
|
|
|
|
------------------------------------------------
|
|
|
|
$ git rev-parse HEAD | git commit-graph write --stdin-commits --append
|
|
|
|
------------------------------------------------
|
|
|
|
|
2018-04-02 22:34:20 +02:00
|
|
|
|
2018-04-02 22:34:18 +02:00
|
|
|
GIT
|
|
|
|
---
|
|
|
|
Part of the linkgit:git[1] suite
|