]> git.ipfire.org Git - thirdparty/git.git/commit - remote.c
transfer doc: move fetch.credentialsInUrl to "transfer" config namespace
authorÆvar Arnfjörð Bjarmason <avarab@gmail.com>
Wed, 15 Jun 2022 10:44:12 +0000 (12:44 +0200)
committerJunio C Hamano <gitster@pobox.com>
Wed, 15 Jun 2022 18:40:11 +0000 (11:40 -0700)
commit7281c196b1166f1c00df33948c67b0ef81ba63a9
tree2275ad64240b68deb80082d52cd5a805a452c72b
parent4a169da280aa6d22bdf0cf5baea65f47bd363a3a
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>
Documentation/RelNotes/2.37.0.txt
Documentation/config/fetch.txt
Documentation/config/transfer.txt
remote.c
t/t5516-fetch-push.sh
t/t5601-clone.sh