Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > The reason why `.pushURL` was not handled as well is that it is way too > common for Git users to call `git clone https://<user>:<password>@<host>` > ... > There is no similar indirect way to leak credentials into `pushURL` Ah, so it is not primarily between .URL vs .pushURL, but the difference is between "clone" that leaves the URL used on the command line in the configuraiton, vs "push" that does not. And because .pushURL has to be explicitly configured by the end-user, there is much less need to remind that they are _storing_ credential material in the configuration files. The reasoning does make sense. > Having said that, I would be in favor of letting > `transfer.credentialsInURL` treat `remote.*.pushURL` in the same manner as > `remote.*.url`. Amen to that. Thanks.