1f010d6bdf
We presently use the ".txt" extension for our AsciiDoc files. While not wrong, most editors do not associate this extension with AsciiDoc, meaning that contributors don't get automatic editor functionality that could be useful, such as syntax highlighting and prose linting. It is much more common to use the ".adoc" extension for AsciiDoc files, since this helps editors automatically detect files and also allows various forges to provide rich (HTML-like) rendering. Let's do that here, renaming all of the files and updating the includes where relevant. Adjust the various build scripts and makefiles to use the new extension as well. Note that this should not result in any user-visible changes to the documentation. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
89 lines
4.0 KiB
Plaintext
89 lines
4.0 KiB
Plaintext
uploadpack.hideRefs::
|
|
This variable is the same as `transfer.hideRefs`, but applies
|
|
only to `upload-pack` (and so affects only fetches, not pushes).
|
|
An attempt to fetch a hidden ref by `git fetch` will fail. See
|
|
also `uploadpack.allowTipSHA1InWant`.
|
|
|
|
uploadpack.allowTipSHA1InWant::
|
|
When `uploadpack.hideRefs` is in effect, allow `upload-pack`
|
|
to accept a fetch request that asks for an object at the tip
|
|
of a hidden ref (by default, such a request is rejected).
|
|
See also `uploadpack.hideRefs`. Even if this is false, a client
|
|
may be able to steal objects via the techniques described in the
|
|
"SECURITY" section of the linkgit:gitnamespaces[7] man page; it's
|
|
best to keep private data in a separate repository.
|
|
|
|
uploadpack.allowReachableSHA1InWant::
|
|
Allow `upload-pack` to accept a fetch request that asks for an
|
|
object that is reachable from any ref tip. However, note that
|
|
calculating object reachability is computationally expensive.
|
|
Defaults to `false`. Even if this is false, a client may be able
|
|
to steal objects via the techniques described in the "SECURITY"
|
|
section of the linkgit:gitnamespaces[7] man page; it's best to
|
|
keep private data in a separate repository.
|
|
|
|
uploadpack.allowAnySHA1InWant::
|
|
Allow `upload-pack` to accept a fetch request that asks for any
|
|
object at all.
|
|
It implies `uploadpack.allowTipSHA1InWant` and
|
|
`uploadpack.allowReachableSHA1InWant`. If set to `true` it will
|
|
enable both of them, it set to `false` it will disable both of
|
|
them.
|
|
By default not set.
|
|
|
|
uploadpack.keepAlive::
|
|
When `upload-pack` has started `pack-objects`, there may be a
|
|
quiet period while `pack-objects` prepares the pack. Normally
|
|
it would output progress information, but if `--quiet` was used
|
|
for the fetch, `pack-objects` will output nothing at all until
|
|
the pack data begins. Some clients and networks may consider
|
|
the server to be hung and give up. Setting this option instructs
|
|
`upload-pack` to send an empty keepalive packet every
|
|
`uploadpack.keepAlive` seconds. Setting this option to 0
|
|
disables keepalive packets entirely. The default is 5 seconds.
|
|
|
|
uploadpack.packObjectsHook::
|
|
If this option is set, when `upload-pack` would run
|
|
`git pack-objects` to create a packfile for a client, it will
|
|
run this shell command instead. The `pack-objects` command and
|
|
arguments it _would_ have run (including the `git pack-objects`
|
|
at the beginning) are appended to the shell command. The stdin
|
|
and stdout of the hook are treated as if `pack-objects` itself
|
|
was run. I.e., `upload-pack` will feed input intended for
|
|
`pack-objects` to the hook, and expects a completed packfile on
|
|
stdout.
|
|
+
|
|
Note that this configuration variable is only respected when it is specified
|
|
in protected configuration (see <<SCOPES>>). This is a safety measure
|
|
against fetching from untrusted repositories.
|
|
|
|
uploadpack.allowFilter::
|
|
If this option is set, `upload-pack` will support partial
|
|
clone and partial fetch object filtering.
|
|
|
|
uploadpackfilter.allow::
|
|
Provides a default value for unspecified object filters (see: the
|
|
below configuration variable). If set to `true`, this will also
|
|
enable all filters which get added in the future.
|
|
Defaults to `true`.
|
|
|
|
uploadpackfilter.<filter>.allow::
|
|
Explicitly allow or ban the object filter corresponding to
|
|
`<filter>`, where `<filter>` may be one of: `blob:none`,
|
|
`blob:limit`, `object:type`, `tree`, `sparse:oid`, or `combine`.
|
|
If using combined filters, both `combine` and all of the nested
|
|
filter kinds must be allowed. Defaults to `uploadpackfilter.allow`.
|
|
|
|
uploadpackfilter.tree.maxDepth::
|
|
Only allow `--filter=tree:<n>` when `<n>` is no more than the value of
|
|
`uploadpackfilter.tree.maxDepth`. If set, this also implies
|
|
`uploadpackfilter.tree.allow=true`, unless this configuration
|
|
variable had already been set. Has no effect if unset.
|
|
|
|
uploadpack.allowRefInWant::
|
|
If this option is set, `upload-pack` will support the `ref-in-want`
|
|
feature of the protocol version 2 `fetch` command. This feature
|
|
is intended for the benefit of load-balanced servers which may
|
|
not have the same view of what OIDs their refs point to due to
|
|
replication delay.
|