summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorÆvar Arnfjörð Bjarmason <avarab@gmail.com>2022-06-15 10:44:12 (GMT)
committerJunio C Hamano <gitster@pobox.com>2022-06-15 18:40:11 (GMT)
commit7281c196b1166f1c00df33948c67b0ef81ba63a9 (patch)
tree2275ad64240b68deb80082d52cd5a805a452c72b /Documentation
parent4a169da280aa6d22bdf0cf5baea65f47bd363a3a (diff)
downloadgit-7281c196b1166f1c00df33948c67b0ef81ba63a9.zip
git-7281c196b1166f1c00df33948c67b0ef81ba63a9.tar.gz
git-7281c196b1166f1c00df33948c67b0ef81ba63a9.tar.bz2
transfer doc: move fetch.credentialsInUrl to "transfer" config namespace
Rename the "fetch.credentialsInUrl" configuration variable introduced in 6dcbdc0d661 (remote: create fetch.credentialsInUrl config, 2022-06-06) to "transfer". There are existing exceptions, but generally speaking the "<namespace>.<var>" configuration should only apply to command described in the "namespace" (and its sub-commands, so e.g. "clone.*" or "fetch.*" might also configure "git-remote-https"). But in the case of "fetch.credentialsInUrl" we've got a configuration variable that configures the behavior of all of "clone", "push" and "fetch", someone adjusting "fetch.*" configuration won't expect to have the behavior of "git push" altered, especially as we have the pre-existing "{transfer,fetch,receive}.fsckObjects", which configures different parts of the transfer dialog. So let's move this configuration variable to the "transfer" namespace before it's exposed in a release. We could add all of "{transfer,fetch,pull}.credentialsInUrl" at some other time, but once we have "fetch" configure "pull" such an arrangement would would be a confusing mess, as we'd at least need to have "fetch" configure "push" (but not the other way around), or change existing behavior. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Acked-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/RelNotes/2.37.0.txt2
-rw-r--r--Documentation/config/fetch.txt36
-rw-r--r--Documentation/config/transfer.txt38
3 files changed, 39 insertions, 37 deletions
diff --git a/Documentation/RelNotes/2.37.0.txt b/Documentation/RelNotes/2.37.0.txt
index 39ca360..9902a74 100644
--- a/Documentation/RelNotes/2.37.0.txt
+++ b/Documentation/RelNotes/2.37.0.txt
@@ -54,7 +54,7 @@ UI, Workflows & Features
* Update the doctype written in gitweb output to xhtml5.
- * The "fetch.credentialsInUrl" configuration variable controls what
+ * The "transfer.credentialsInUrl" configuration variable controls what
happens when a URL with embedded login credential is used on either
"fetch" or "push". Credentials are currently only detected in
`remote.<name>.url` config, not `remote.<name>.pushurl`.
diff --git a/Documentation/config/fetch.txt b/Documentation/config/fetch.txt
index 8279610..cd65d23 100644
--- a/Documentation/config/fetch.txt
+++ b/Documentation/config/fetch.txt
@@ -96,39 +96,3 @@ fetch.writeCommitGraph::
merge and the write may take longer. Having an updated commit-graph
file helps performance of many Git commands, including `git merge-base`,
`git push -f`, and `git log --graph`. Defaults to false.
-
-fetch.credentialsInUrl::
- A configured URL can contain plaintext credentials in the form
- `<protocol>://<user>:<password>@<domain>/<path>`. You may want
- to warn or forbid the use of such configuration (in favor of
- using linkgit:git-credential[1]).
-+
-Note that this is currently limited to detecting credentials in
-`remote.<name>.url` configuration, it won't detect credentials in
-`remote.<name>.pushurl` configuration.
-+
-You might want to enable this to prevent inadvertent credentials
-exposure, e.g. because:
-+
-* The OS or system where you're running git may not provide way way or
- otherwise allow you to configure the permissions of the
- configuration file where the username and/or password are stored.
-* Even if it does, having such data stored "at rest" might expose you
- in other ways, e.g. a backup process might copy the data to another
- system.
-* The git programs will pass the full URL to one another as arguments
- on the command-line, meaning the credentials will be exposed to oher
- users on OS's or systems that allow other users to see the full
- process list of other users. On linux the "hidepid" setting
- documented in procfs(5) allows for configuring this behavior.
-+
-If such concerns don't apply to you then you probably don't need to be
-concerned about credentials exposure due to storing that sensitive
-data in git's configuration files. If you do want to use this, set
-`fetch.credentialsInUrl` to one of these values:
-+
-* `allow` (default): Git will proceed with its activity without warning.
-* `warn`: Git will write a warning message to `stderr` when parsing a URL
- with a plaintext credential.
-* `die`: Git will write a failure message to `stderr` when parsing a URL
- with a plaintext credential.
diff --git a/Documentation/config/transfer.txt b/Documentation/config/transfer.txt
index b49429e..b4475c0 100644
--- a/Documentation/config/transfer.txt
+++ b/Documentation/config/transfer.txt
@@ -1,3 +1,41 @@
+transfer.credentialsInUrl::
+ A configured URL can contain plaintext credentials in the form
+ `<protocol>://<user>:<password>@<domain>/<path>`. You may want
+ to warn or forbid the use of such configuration (in favor of
+ using linkgit:git-credential[1]). This will be used on
+ linkgit:git-clone[1], linkgit:git-fetch[1], linkgit:git-push[1],
+ and any other direct use of the configured URL.
++
+Note that this is currently limited to detecting credentials in
+`remote.<name>.url` configuration, it won't detect credentials in
+`remote.<name>.pushurl` configuration.
++
+You might want to enable this to prevent inadvertent credentials
+exposure, e.g. because:
++
+* The OS or system where you're running git may not provide way way or
+ otherwise allow you to configure the permissions of the
+ configuration file where the username and/or password are stored.
+* Even if it does, having such data stored "at rest" might expose you
+ in other ways, e.g. a backup process might copy the data to another
+ system.
+* The git programs will pass the full URL to one another as arguments
+ on the command-line, meaning the credentials will be exposed to oher
+ users on OS's or systems that allow other users to see the full
+ process list of other users. On linux the "hidepid" setting
+ documented in procfs(5) allows for configuring this behavior.
++
+If such concerns don't apply to you then you probably don't need to be
+concerned about credentials exposure due to storing that sensitive
+data in git's configuration files. If you do want to use this, set
+`transfer.credentialsInUrl` to one of these values:
++
+* `allow` (default): Git will proceed with its activity without warning.
+* `warn`: Git will write a warning message to `stderr` when parsing a URL
+ with a plaintext credential.
+* `die`: Git will write a failure message to `stderr` when parsing a URL
+ with a plaintext credential.
+
transfer.fsckObjects::
When `fetch.fsckObjects` or `receive.fsckObjects` are
not set, the value of this variable is used instead.