git/Documentation/git-clone.txt, branch v2.48.2

Merge branch 'bc/allow-upload-pack-from-other-people'

2024-12-10T01:04:55Z

Loosen overly strict ownership check introduced in the recent past, to keep the promise "cloning a suspicious repository is a safe first step to inspect it". * bc/allow-upload-pack-from-other-people: Allow cloning from repositories owned by another user

Allow cloning from repositories owned by another user

2024-11-15T02:05:06Z

Historically, Git has allowed users to clone from an untrusted repository, and we have documented that this is safe to do so: `upload-pack` tries to avoid any dangerous configuration options or hooks from the repository it's serving, making it safe to clone an untrusted directory and run commands on the resulting clone. However, this was broken by f4aa8c8bb1 ("fetch/clone: detect dubious ownership of local repositories", 2024-04-10) in an attempt to make things more secure. That change resulted in a variety of problems when cloning locally and over SSH, but it did not change the stated security boundary. Because the security boundary has not changed, it is safe to adjust part of the code that patch introduced. To do that and restore the previous functionality, adjust enter_repo to take two flags instead of one. The two bits are - ENTER_REPO_STRICT: callers that require exact paths (as opposed to allowing known suffixes like ".git", ".git/.git" to be omitted) can set this bit. Corresponds to the "strict" parameter that the flags word replaces. - ENTER_REPO_ANY_OWNER_OK: callers that are willing to run without ownership check can set this bit. The former is --strict-paths option of "git daemon". The latter is set only by upload-pack, which honors the claimed security boundary. Note that local clones across ownership boundaries require --no-local so that upload-pack is used. Document this fact in the manual page and provide an example. This patch was based on one written by Junio C Hamano. Signed-off-by: Junio C Hamano

doc: correct misleading descriptions for --shallow-exclude

2024-11-05T06:53:23Z

The documentation for the --shallow-exclude option to clone/fetch/etc. claims that the option takes a revision, but it does not. As per upload-pack.c's process_deepen_not(), it passes the option to expand_ref() and dies if it does not find exactly one ref matching the name passed. Further, this has always been the case ever since these options were introduced by the commits merged in a460ea4a3cb1 (Merge branch 'nd/shallow-deepen', 2016-10-10). Fix the documentation to match the implementation. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

Merge branch 'xx/remote-server-option-config'

2024-10-15T20:56:43Z

A new configuration variable remote..serverOption makes the transport layer act as if the --serverOption= option is given from the command line. * xx/remote-server-option-config: ls-remote: leakfix for not clearing server_options fetch: respect --server-option when fetching multiple remotes transport.c::handshake: make use of server options from remote remote: introduce remote..serverOption configuration transport: introduce parse_transport_option() method

transport.c::handshake: make use of server options from remote

2024-10-08T17:22:08Z

Utilize the `server_options` from the corresponding remote during the handshake in `transport.c` when Git protocol v2 is detected. This helps initialize the `server_options` in `transport.h:transport` if no server options are set for the transport (typically via `--server-option` or `-o`). While another potential place to incorporate server options from the remote is in `transport.c:transport_get`, setting server options for a transport using a protocol other than v2 could lead to unexpected errors (see `transport.c:die_if_server_options`). Relevant tests and documentation have been updated accordingly. Signed-off-by: Xing Xin Reviewed-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

doc: apply synopsis simplification on git-clone and git-init

2024-09-24T17:20:26Z

With the new synopsis formatting backend, no special asciidoc markup is needed. Signed-off-by: Jean-Noël Avila Signed-off-by: Junio C Hamano

doc: git-clone fix discrepancy between asciidoc and asciidoctor

2024-07-20T23:24:12Z

Asciidoc.py does not have the concept of generalized roles, whereas asciidoctor interprets [foo]`blah` as blah with role foo in the synopsis, making in effect foo disappear in the output. Note that square brackets not directly followed by an inline markup do not define a role, which is why we do not have the issue on other parts of the documentation. In order to get a consistant result across asciidoctor and asciidoc.py, the hack is to use the {empty} entity to split the bracket part from the inline format part. Signed-off-by: Jean-Noël Avila Signed-off-by: Junio C Hamano

doc: git-clone: apply new documentation formatting guidelines

2024-03-29T17:57:40Z

Signed-off-by: Jean-Noël Avila Signed-off-by: Junio C Hamano

Merge branch 'ja/doc-markup-fixes'

2024-03-21T21:55:13Z

Mark-ups used in the documentation has been improved for consistency. * ja/doc-markup-fixes: doc: git-clone: format placeholders doc: git-clone: format verbatim words doc: git-init: rework config item init.templateDir doc: git-init: rework definition lists doc: git-init: format placeholders doc: git-init: format verbatim parts

doc: git-clone: format placeholders

2024-03-11T16:58:11Z

With the new formatting rules, we use __. Signed-off-by: Jean-Noël Avila Signed-off-by: Junio C Hamano