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