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:
signature.asc
Description: PGP signature
