2020-07-29 23:14:27 +00:00
|
|
|
extensions.objectFormat::
|
|
|
|
Specify the hash algorithm to use. The acceptable values are `sha1` and
|
|
|
|
`sha256`. If not specified, `sha1` is assumed. It is an error to specify
|
|
|
|
this key unless `core.repositoryFormatVersion` is 1.
|
|
|
|
+
|
|
|
|
Note that this setting should only be set by linkgit:git-init[1] or
|
|
|
|
linkgit:git-clone[1]. Trying to change it after initialization will not
|
|
|
|
work and will produce hard-to-diagnose issues.
|
2022-02-07 21:32:58 +00:00
|
|
|
|
2023-10-02 02:40:25 +00:00
|
|
|
extensions.compatObjectFormat::
|
|
|
|
|
|
|
|
Specify a compatitbility hash algorithm to use. The acceptable values
|
|
|
|
are `sha1` and `sha256`. The value specified must be different from the
|
|
|
|
value of extensions.objectFormat. This allows client level
|
|
|
|
interoperability between git repositories whose objectFormat matches
|
|
|
|
this compatObjectFormat. In particular when fully implemented the
|
|
|
|
pushes and pulls from a repository in whose objectFormat matches
|
|
|
|
compatObjectFormat. As well as being able to use oids encoded in
|
|
|
|
compatObjectFormat in addition to oids encoded with objectFormat to
|
|
|
|
locally specify objects.
|
|
|
|
|
setup: introduce "extensions.refStorage" extension
Introduce a new "extensions.refStorage" extension that allows us to
specify the ref storage format used by a repository. For now, the only
supported format is the "files" format, but this list will likely soon
be extended to also support the upcoming "reftable" format.
There have been discussions on the Git mailing list in the past around
how exactly this extension should look like. One alternative [1] that
was discussed was whether it would make sense to model the extension in
such a way that backends are arbitrarily stackable. This would allow for
a combined value of e.g. "loose,packed-refs" or "loose,reftable", which
indicates that new refs would be written via "loose" files backend and
compressed into "packed-refs" or "reftable" backends, respectively.
It is arguable though whether this flexibility and the complexity that
it brings with it is really required for now. It is not foreseeable that
there will be a proliferation of backends in the near-term future, and
the current set of existing formats and formats which are on the horizon
can easily be configured with the much simpler proposal where we have a
single value, only.
Furthermore, if we ever see that we indeed want to gain the ability to
arbitrarily stack the ref formats, then we can adapt the current
extension rather easily. Given that Git clients will refuse any unknown
value for the "extensions.refStorage" extension they would also know to
ignore a stacked "loose,packed-refs" in the future.
So let's stick with the easy proposal for the time being and wire up the
extension.
[1]: <pull.1408.git.1667846164.gitgitgadget@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-12-29 07:26:47 +00:00
|
|
|
extensions.refStorage::
|
|
|
|
Specify the ref storage format to use. The acceptable values are:
|
|
|
|
+
|
|
|
|
include::../ref-storage-format.txt[]
|
|
|
|
+
|
|
|
|
It is an error to specify this key unless `core.repositoryFormatVersion` is 1.
|
|
|
|
+
|
|
|
|
Note that this setting should only be set by linkgit:git-init[1] or
|
|
|
|
linkgit:git-clone[1]. Trying to change it after initialization will not
|
|
|
|
work and will produce hard-to-diagnose issues.
|
|
|
|
|
2022-02-07 21:32:58 +00:00
|
|
|
extensions.worktreeConfig::
|
|
|
|
If enabled, then worktrees will load config settings from the
|
|
|
|
`$GIT_DIR/config.worktree` file in addition to the
|
|
|
|
`$GIT_COMMON_DIR/config` file. Note that `$GIT_COMMON_DIR` and
|
|
|
|
`$GIT_DIR` are the same for the main working tree, while other
|
|
|
|
working trees have `$GIT_DIR` equal to
|
|
|
|
`$GIT_COMMON_DIR/worktrees/<id>/`. The settings in the
|
|
|
|
`config.worktree` file will override settings from any other
|
|
|
|
config files.
|
|
|
|
+
|
|
|
|
When enabling `extensions.worktreeConfig`, you must be careful to move
|
|
|
|
certain values from the common config file to the main working tree's
|
|
|
|
`config.worktree` file, if present:
|
|
|
|
+
|
|
|
|
* `core.worktree` must be moved from `$GIT_COMMON_DIR/config` to
|
|
|
|
`$GIT_COMMON_DIR/config.worktree`.
|
|
|
|
* If `core.bare` is true, then it must be moved from `$GIT_COMMON_DIR/config`
|
|
|
|
to `$GIT_COMMON_DIR/config.worktree`.
|
|
|
|
+
|
|
|
|
It may also be beneficial to adjust the locations of `core.sparseCheckout`
|
|
|
|
and `core.sparseCheckoutCone` depending on your desire for customizable
|
|
|
|
sparse-checkout settings for each worktree. By default, the `git
|
|
|
|
sparse-checkout` builtin enables `extensions.worktreeConfig`, assigns
|
|
|
|
these config values on a per-worktree basis, and uses the
|
|
|
|
`$GIT_DIR/info/sparse-checkout` file to specify the sparsity for each
|
|
|
|
worktree independently. See linkgit:git-sparse-checkout[1] for more
|
|
|
|
details.
|
|
|
|
+
|
|
|
|
For historical reasons, `extensions.worktreeConfig` is respected
|
|
|
|
regardless of the `core.repositoryFormatVersion` setting.
|