git/Documentation/RelNotes, branch v2.37.0-rc2

Git 2.37-rc1

2022-06-18T00:15:13Z

Signed-off-by: Junio C Hamano

Another batch of fixes before -rc1

2022-06-17T17:33:42Z

Signed-off-by: Junio C Hamano

Merge branch 'ab/credentials-in-url-more'

2022-06-17T17:33:32Z

Rename fetch.credentialsInUrl to transfer.credentialsInUrl as the single configuration variable should work both in pushing and fetching. * ab/credentials-in-url-more: transfer doc: move fetch.credentialsInUrl to "transfer" config namespace fetch doc: note "pushurl" caveat about "credentialsInUrl", elaborate

Fixes and updates post -rc0

2022-06-15T22:09:35Z

Signed-off-by: Junio C Hamano

transfer doc: move fetch.credentialsInUrl to "transfer" config namespace

2022-06-15T18:40:11Z

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 "." 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 Acked-by: Derrick Stolee Signed-off-by: Junio C Hamano

fetch doc: note "pushurl" caveat about "credentialsInUrl", elaborate

2022-06-15T18:39:02Z

Amend the documentation and release notes entry for the "fetch.credentialsInUrl" feature added in 6dcbdc0d661 (remote: create fetch.credentialsInUrl config, 2022-06-06), it currently doesn't detect passwords in `remote..pushurl` configuration. We shouldn't lull users into a false sense of security, so we need to mention that prominently. This also elaborates and clarifies the "exposes the password in multiple ways" part of the documentation. As noted in [1] a user unfamiliar with git's implementation won't know what to make of that scary claim, e.g. git hypothetically have novel git-specific ways of exposing configured credentials. The reality is that this configuration is intended as an aid for users who can't fully trust their OS's or system's security model, so lets say that's what this is intended for, and mention the most common ways passwords stored in configuration might inadvertently get exposed. 1. https://lore.kernel.org/git/220524.86ilpuvcqh.gmgdl@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason Acked-by: Derrick Stolee Signed-off-by: Junio C Hamano

Git 2.37-rc0

2022-06-13T22:53:44Z

Signed-off-by: Junio C Hamano

Ninth batch

2022-06-10T22:05:15Z

Signed-off-by: Junio C Hamano

Sync with 'maint'

2022-06-08T21:29:30Z

Prepare for 2.36.2

2022-06-08T21:27:53Z

Signed-off-by: Junio C Hamano