Jeff King <peff@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html