The global "remote.origin.push" takes precedence over the local "remote.origin.push".

[elpiekay]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.22.0.windows.1
cpu: x86_64
built from commit: d003d728ffa6c0006da875ec6318d3f6b28a4ddb
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [版本 6.1.7601]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VisualStudioCode
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: LFOnly
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled
Enable Builtin Interactive Add: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

No.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Git Bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

# create simulation repos
git init --bare server
git clone server client

# set global and local config
git config --global remote.origin.push refs/heads/*:refs/for/*
cd client
git config remote.origin.push refs/heads/*:refs/heads/*

# create and push "master"
touch a.txt
git add a.txt
git commit -m foo
git push origin master

• What did you expect to occur after running these commands?

 To ../server
   * [new branch]      master -> master 

As the local config take higher precedence than the global config, "refs/heads/*:refs/heads/*" is expected to take effect.

• What actually happened instead?

 To ../server
   * [new branch]      master -> refs/world/master 

However it seems the global config takes precedence.

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

[PhilipOakley]

Have you been able to test if this is a Windows only problem, or one that should be reported upstream?

A relatively easy test is to use the WSL (Windows Subsystem for Linux), which provides a linux version that can be used for comparison.

[elpiekay]

Have you been able to test if this is a Windows only problem, or one that should be reported upstream?

A relatively easy test is to use the WSL (Windows Subsystem for Linux), which provides a linux version that can be used for comparison.

@PhilipOakley I tried on Ubuntu and the result is the same. I edited and updated the commands to test.

Distributor ID: Ubuntu
Description:    Ubuntu 12.04.2 LTS
Release:        12.04
Codename:       precise

git version 2.19.2
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8

[PhilipOakley]

Have you checked that there's not some documentation confusion (one part giving different info compared to another part) regarding priorities? (just in case it's a doc issue;-).

Otherwise it's probably best reported upstream to the dev's list git@vger.kernel.org (plain text, absolutely no HTML, expect slight delay for first email), though others here on the windows list may also be able to help.

[dscho]

The documentation on this is not terribly clear, but remote.<name>.push has always intended to be a multi-var configuration (i.e. accumulating refspecs, rather than overriding all but the last one): https://github.com/git/git/blob/v2.22.0/remote.c#L391-L395

Further, in contrast to other multi-var config options, remote.<name>.push does not have a special value that resets the accumulated list. The credential.helper, for example, resets the list of credential helpers parsed so far when it encounters an empty value. This is not the case for remote.<name>.push, and my best guess is that nobody expected any user to configure their push refspecs in anything but the repository's config.

Is there any reason why you want this in the global config? (It does not make all that much sense to me, I have to admit.)

And yes, not a Windows-specific issue in the least. This is Git's behavior you described.

[elpiekay]

Have you checked that there's not some documentation confusion (one part giving different info compared to another part) regarding priorities? (just in case it's a doc issue;-).

Otherwise it's probably best reported upstream to the dev's list git@vger.kernel.org (plain text, absolutely no HTML, expect slight delay for first email), though others here on the windows list may also be able to help.

@PhilipOakley So far I can't find any convincing description in any document.

[dscho]

So far I can't find any convincing description in any document.

Did you read the link into the source code I gave you earlier? It is not documentation, but so far I think it is the best you got.

[elpiekay]

The documentation on this is not terribly clear, but remote.<name>.push has always intended to be a multi-var configuration (i.e. accumulating refspecs, rather than overriding all but the last one): https://github.com/git/git/blob/v2.22.0/remote.c#L391-L395

Further, in contrast to other multi-var config options, remote.<name>.push does not have a special value that resets the accumulated list. The credential.helper, for example, resets the list of credential helpers parsed so far when it encounters an empty value. This is not the case for remote.<name>.push, and my best guess is that nobody expected any user to configure their push refspecs in anything but the repository's config.

Is there any reason why you want this in the global config? (It does not make all that much sense to me, I have to admit.)

And yes, not a Windows-specific issue in the least. This is Git's behavior you described.

@dscho In my case, I have several thousand repos. Most of them are hosted in Gerrit and the rest in Gitlab. Gerrit requires a refspec refs/heads/*:refs/for/* to create a pending change for review. So I intent to set the global remote.origin.push=refs/heads/*:refs/for/* for Gerrit repos and the local remote.origin.push=refs/heads/*:refs/heads/* for Gitlab repos.

The code explains something but is still not that convincing, and I've found an inconsistent behaviour.

# Case 1
global refs/heads/*:refs/for/*
local refs/heads/master:refs/heads/master

# Case 2
global refs/heads/master:refs/for/master
local refs/heads/*:refs/heads/*

# Case 3
global refs/heads/master:refs/for/master
local refs/heads/master:refs/heads/master

In all the 3 cases, both refs/for/master and master are created, although I've been expecting only master to be. When both use glob refspecs, the local variable is ignored.

[elpiekay]

When the system variable is included,

# Case 1
system refs/heads/*:refs/hello/*
global refs/heads/*:refs/for/*
local refs/heads/*:refs/heads/*

Only refs/hello/master is created.

# Case 2
system refs/heads/*:refs/hello/*
global refs/heads/master:refs/for/master
local refs/heads/*:refs/heads/*

refs/for/master and refs/hello/master are created.

# Case 3
system refs/heads/*:refs/hello/*
global refs/heads/*:refs/for/*
local refs/heads/master:refs/heads/master

master and refs/hello/master are created.

# Case 4
system refs/heads/*:refs/hello/*
global refs/heads/master:refs/for/master
local refs/heads/master:refs/heads/master

refs/for/master, master and refs/hello/master are created.

# Case 5
system refs/heads/master:refs/hello/master
global refs/heads/*:refs/for/*
local refs/heads/*:refs/heads/*

refs/hello/master and refs/for/master are created.

# Case 6
system refs/heads/master:refs/hello/master
global refs/heads/master:refs/for/master
local refs/heads/*:refs/heads/*

refs/for/master, master and refs/hello/master are created.

# Case 7
system refs/heads/master:refs/hello/master
global refs/heads/*:refs/for/*
local refs/heads/master:refs/heads/master

refs/for/master, master and refs/hello/master are created.

# Case 8
system refs/heads/master:refs/hello/master
global refs/heads/master:refs/for/master
local refs/heads/master:refs/heads/master

refs/for/master, master and refs/hello/master are created.

[dscho]

And yes, not a Windows-specific issue in the least. This is Git's behavior you described.

This is still true. As such, @PhilipOakley's suggestion to report this to the Git project itself (not the much tinier Windows port) would make most sense.

[dscho]

This is not a Windows-specific issue. Please take it to the Git mailing list (send plain-text messages, HTML messages are dropped silently).