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