Re: [ITCH] Specify refspec without remote

Jeff King [off-list ref] writes:

On Tue, Apr 09, 2013 at 06:19:01PM -0700, Junio C Hamano wrote:

quoted

quoted

	git push -- master next; # push two refs to default remote

... or default "push remote" if there is one, I presume?

As you are giving what to push, I am assuming that
branch.$name.remote would not come into play in this case.

...
The missing case 4 is obviously:

  dst=missing, refs=present
...
Do you want to explain your thinking? I'm guessing it has to do with the
fact that choosing branch.*.remote is about trying to push to the
configured upstream (even though we traditionally do _not_ take into
account branch.*.merge when doing so).

With the branch.$name.remote, the user tells us "When I am on this
branch, I want to talk to this remote".  When you did

	git push -- master next ;# case #4

on branch maint, branch.maint.remote should not come into play.

Would we want to push our 'master' to branch.master.remote in a way 

	git checkout master && git push

would do, while at the same time because we were told to do the same
for 'next', we do the same as

	git checkout next && git push

would do?  That would work if you give just branch names, but that
is not a general enough definition to cover your case #4, e.g.

	git push -- v1.2.3 master:refs/remotes/mothership/master

If we define case #4 to push to the remote.pushdefault (falling back
to remote.default), this case would do what can simply be expected;
if the earlier cases also push to that same place, ignoring
branch.$name.remote for master and next, that would be consistent.