2018-10-27 08:23:25 +02:00
|
|
|
protocol.allow::
|
|
|
|
|
If set, provide a user defined default policy for all protocols which
|
|
|
|
|
don't explicitly have a policy (`protocol.<name>.allow`). By default,
|
|
|
|
|
if unset, known-safe protocols (http, https, git, ssh, file) have a
|
|
|
|
|
default policy of `always`, known-dangerous protocols (ext) have a
|
|
|
|
|
default policy of `never`, and all other protocols have a default
|
|
|
|
|
policy of `user`. Supported policies:
|
|
|
|
|
+
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
* `always` - protocol is always able to be used.
|
|
|
|
|
|
|
|
|
|
* `never` - protocol is never able to be used.
|
|
|
|
|
|
|
|
|
|
* `user` - protocol is only able to be used when `GIT_PROTOCOL_FROM_USER` is
|
|
|
|
|
either unset or has a value of 1. This policy should be used when you want a
|
|
|
|
|
protocol to be directly usable by the user but don't want it used by commands which
|
|
|
|
|
execute clone/fetch/push commands without user input, e.g. recursive
|
|
|
|
|
submodule initialization.
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
protocol.<name>.allow::
|
|
|
|
|
Set a policy to be used by protocol `<name>` with clone/fetch/push
|
|
|
|
|
commands. See `protocol.allow` above for the available policies.
|
|
|
|
|
+
|
|
|
|
|
The protocol names currently used by git are:
|
|
|
|
|
+
|
|
|
|
|
--
|
|
|
|
|
- `file`: any local file-based path (including `file://` URLs,
|
|
|
|
|
or local paths)
|
|
|
|
|
|
|
|
|
|
- `git`: the anonymous git protocol over a direct TCP
|
|
|
|
|
connection (or proxy, if configured)
|
|
|
|
|
|
|
|
|
|
- `ssh`: git over ssh (including `host:path` syntax,
|
|
|
|
|
`ssh://`, etc).
|
|
|
|
|
|
|
|
|
|
- `http`: git over http, both "smart http" and "dumb http".
|
|
|
|
|
Note that this does _not_ include `https`; if you want to configure
|
|
|
|
|
both, you must do so individually.
|
|
|
|
|
|
|
|
|
|
- any external helpers are named by their protocol (e.g., use
|
|
|
|
|
`hg` to allow the `git-remote-hg` helper)
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
protocol.version::
|
2019-12-24 02:00:00 +01:00
|
|
|
If set, clients will attempt to communicate with a server
|
|
|
|
|
using the specified protocol version. If the server does
|
|
|
|
|
not support it, communication falls back to version 0.
|
protocol: re-enable v2 protocol by default
Protocol v2 became the default in v2.26.0 via 684ceae32d (fetch: default
to protocol version 2, 2019-12-23). More widespread use turned up a
regression in negotiation. That was fixed in v2.27.0 via 4fa3f00abb
(fetch-pack: in protocol v2, in_vain only after ACK, 2020-04-27), but we
also reverted the default to v0 as a precuation in 11c7f2a30b (Revert
"fetch: default to protocol version 2", 2020-04-22).
In v2.28.0, we re-enabled it for experimental users with 3697caf4b9
(config: let feature.experimental imply protocol.version=2, 2020-05-20)
and haven't heard any complaints. v2.28 has only been out for 2 months,
but I'd generally expect people turning on feature.experimental to also
stay pretty up-to-date. So we're not likely to collect much more data by
waiting. In addition, we have no further reports from people running
v2.26.0, and of course some people have been setting protocol.version
manually for ages.
Let's move forward with v2 as the default again. It's possible there are
still lurking bugs, but we won't know until it gets more widespread use.
And we can find and squash them just like any other bug at this point.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-25 20:34:36 +02:00
|
|
|
If unset, the default is `2`.
|
2018-10-27 08:23:25 +02:00
|
|
|
Supported versions:
|
|
|
|
|
+
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
* `0` - the original wire protocol.
|
|
|
|
|
|
|
|
|
|
* `1` - the original wire protocol with the addition of a version string
|
|
|
|
|
in the initial response from the server.
|
|
|
|
|
|
|
|
|
|
* `2` - link:technical/protocol-v2.html[wire protocol version 2].
|
|
|
|
|
|
|
|
|
|
--
|