Multiple urls for remotes?

Multiple urls for remotes?

[Mike Hommey]

Hi,

I was surprised to figure out that urls/pushurls set up for remotes can
be set multiple times, and that those urls end up being used
sequentially.

Sadly, this has the side effect that one cannot override the config from
the command line, as the url is then added as an extra url, which is
tried after the already configured one.

e.g.
    git -c remote.origin.url=/tmp/foo push origin

will keep pushing to wherever the .git/config's remote.origin.url points
to.

With all the configuration items that work this way, it's actually kind
of sad that it's not possible to force the value from the command line to
override anything that is set in the configuration.

It's worth noting that the documentation for -c says:

    Pass a configuration parameter to the command. The value given will
    override values from configuration files.

... which implies -c remote.origin.url=/tmp/foo should, in fact, replace
any other value already set.

Coming back to the fact that remote.origin.url and remote.origin.pushurl
can actually have multiple values, it's also worth noting that none of
the git-config, git-fetch or git-push documentation seem to say anything
about the fact there can be multiple values.

The git-config documentation says:
   remote.<name>.url
       The URL of a remote repository. See git-fetch(1) or git-push(1).

   remote.<name>.pushurl
       The push URL of a remote repository. See git-push(1).

The git-fetch and git-push documentations always talk about _the_ URL.

The only thing that seems to be talking about this is the documentation
for git-remote, which has --add for set-url. There doesn't seem to be any
documentation about what conditions are required for the non-primary URL
to be used.

Mike

Re: Multiple urls for remotes?

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]

On 2019-06-26 at 23:52:47, Mike Hommey wrote:
> Hi,
> 
> I was surprised to figure out that urls/pushurls set up for remotes can
> be set multiple times, and that those urls end up being used
> sequentially.

Yes, this is actually a feature. It's useful when you want to push to
multiple remotes at once. For instance, I want to push my Git changes to
both my server and to GitHub, and I can do so simply with "git push def
HEAD".

> Sadly, this has the side effect that one cannot override the config from
> the command line, as the url is then added as an extra url, which is
> tried after the already configured one.
> 
> e.g.
>     git -c remote.origin.url=/tmp/foo push origin
> 
> will keep pushing to wherever the .git/config's remote.origin.url points
> to.
>
> With all the configuration items that work this way, it's actually kind
> of sad that it's not possible to force the value from the command line to
> override anything that is set in the configuration.

This is true for all config options that operate on multiple items, and
it's a known limitation. Some configuration options allow specifying an
empty value to reset the list, but this isn't one of them.

This also tends to bite people when they have set things like refspecs
for origin in their ~/.gitconfig, but then decide they don't want that
behavior on a repo basis.

There was some discussion of this issue in a subthread of my multiple
hooks series recently. In order to have a standard way to reset this,
we'd either need to have each configuration option learn how to reset
itself or we'd need to buffer configuration options until all of the
values are parsed and ignore things before the reset marker. We'd also
need a standard reset marker that can be used consistently. Nobody has
yet picked this up, but of course patches are welcome.

> It's worth noting that the documentation for -c says:
> 
>     Pass a configuration parameter to the command. The value given will
>     override values from configuration files.
> 
> ... which implies -c remote.origin.url=/tmp/foo should, in fact, replace
> any other value already set.

I agree this is a bug. It should probably say something like, "The
values given will act as though they were parsed after the repository
configuration," although we'd need to make it less confusing than that.

> The only thing that seems to be talking about this is the documentation
> for git-remote, which has --add for set-url. There doesn't seem to be any
> documentation about what conditions are required for the non-primary URL
> to be used.

For pushes, it's either always used or it's used if preceding URLs have
not failed, I can't remember which. Only the first URL is used for
fetches. I agree that better documentation here would be desirable as
well.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]