Does not respect push.default

[prof7bit]

I have two different remotes: origin and fork
I have two local branches: master and fork-master

I have setup tracking as such:

[remote "origin"]
       url = https://[somewhere].git
       fetch = +refs/heads/*:refs/remotes/origin/*

[remote "fork"]
       url = git@[somewhere].git
       fetch = +refs/heads/*:refs/remotes/fork/*

[branch "master"]
       remote = origin
       merge = refs/heads/master

[branch "fork-master"]
       remote = fork
       merge = refs/heads/master

I have set push.default to upstream

When I am on the fork-master branch and say "git push" without anything else
in the console it will correctly push to master on fork

If I am in git-gui and press the push button, have "fork-master" selected as
my local branch and "fork" as my remote and press "push" it will create a new
branch "fork-master" on my remote. I would have expected the same result as
in the console.

I have found a setting "match tracking branches" but it does not seem to
have a effect on anything whatsoever, no matter if I enable or disable it,
the behavior will stay exactly the same.

[PhilipOakley]

If I am in git-gui and press the push button,

I don't think the git-gui respects the push.default in the sense that the dialog pane won't [does not appear to] pre-select the correct push remote.

It is something I've noted in my set up. (the upstream repos for many of my branches are on read only remotes, my push.remote is called my - short and sweet). I would have expected that the push dialog preselect the push.default remote name if set.

I have set push.default to "upstream"

Is that verbatim? surely it should be "fork" (assuming there isn't confusion between the remotes and their names..)

[prof7bit]

I have set push.default to "upstream"

Is that verbatim? surely it should be "fork" (assuming there isn't confusion between the remotes and their names..)

Yes, this is one of the 5 allowed options of git config push.default, it controls the bahaviour of git push when you don't give any additional arguments specifying which branch exactly you want to be the destination on the remote side:

• nothing: do not push anything
• matching: (default before Git 2.0) push all matching branches. All branches having the same name in both ends are considered to be matching.
• upstream: push the current branch to its upstream branch (tracking is a deprecated synonym for upstream)
• current: push the current branch to a branch of the same name
• simple: (new in Git 1.7.11, default since Git 2.0) like upstream, but refuses to push if the upstream branch's name is different from the local one

I would have expected git gui to just call git push $remote $localbranch ($remote being the name "fork" in my case and $localbranch would be "fork-master"), there are no other things to select in this dialog, so it would not need to come up with additional options to force git to do anything other than what it would normally do by default given these two arguments, which would under this configuration automatically look up the configured tracking branch for "fork-master" which happens to be "master" in the remote "fork" because that has been configured with --set-upstream for that branch.

In the console if I am on the fork-master branch and just say "git push" it will push to fork/master, because I have configured this previously with --set-upstream.

$ git push -v
Push nach [email protected]:<somewhere>.git
To github.com:<somewhere>.git
 = [up to date]      fork-master -> master
updating local tracking ref 'refs/remotes/fork/master'
Everything up-to-date

$ git push -v fork fork-master 
Push nach [email protected]:<somewhere>.git
To github.com:<somewhere>.git
 = [up to date]      fork-master -> master
updating local tracking ref 'refs/remotes/fork/master'
Everything up-to-date

[PhilipOakley]

Yes, this is one of the 5 allowed options of git config push.default

Ah, thanks. I was miss-remembering the setup for setting the push default to be different from the declared upstream.

The 'dot' (period) is in a different place..

my local config has

[remote]
	pushDefault = my
[remote "my"]
	pushurl = [email protected]:PhilipOakley/git.git
...

I think the git gui constructs the command from the various options in the push dialog, but I haven't checked.

[Gnlfz007]

Is there a workaround for this annoying issue? I frequently end up pushing a branch to the wrong remote because I miss to select the correct branch manually in the push form. A "git push" on the command line selects the correct remote, as reported by "git branch -vv".
git-gui should propose the following remote in the push form:

git config --get branch.$(git branch --show-current).remote

This issue should be considered as a major-major usability bug to be fixed.

[PhilipOakley]

I think the place to add the checks is

C:\git-sdk-64\usr\src\git\git-gui\lib\transport.tcl#L176 (mine /GithubURL ;-)

The task, get the current branch name, and then it's (push) remote, if it has one.

Then get the remote.pushdefault, if present.

Finally (existing code) use 'origin', or top of the list of remotes if nothing else.

I haven't worked my way around to working out how the gui holds it copy of the config for extracting those values.

A little bit of pseudocode for the pushDefault step, but needs work ;-)

		grid $w.dest.remote_r $w.dest.remote_m -sticky w
		set $pushDefault {git config --get remote.pushDefault?}
		if {[lsearch -sorted -exact $all_remotes $pushDefault] != -1} {
			set push_remote $pushDefault
		} elseif {[lsearch -sorted -exact $all_remotes origin] != -1} {
			set push_remote origin
		} else {
			set push_remote [lindex $all_remotes 0]
		}