Jeff King <> writes:

> On Tue, Apr 09, 2013 at 06:19:01PM -0700, Junio C Hamano wrote:
>> >    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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to