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.
On Wed, Apr 10, 2013 at 09:37:01AM -0700, Junio C Hamano wrote:
quoted
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.
I understand that's your position, but I don't understand _why_.
If branch.$name.remote is "when I am on this branch, I want to talk to
this remote", that rule is not be impacted by the presence of refspecs
at all.
If it meant "when I am on this branch, and I do not specify any
refspecs, then I would by default want to push this branch to that
remote", then your proposed behavior would make more sense. And if you
are using push.default=upstream, that is what happens.
But historically the default push has been "matching". So in your other
examples:
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
These do not have anything to do with pushing the checked-out branch in
particular. The first one may very well be pushing "next" to the remote
specified by branch.master.remote.
So I would argue that one of these two makes sense:
1. branch.*.remote means "use this as the default remote on this
branch, no matte which refs we are pushing"
2. branch.*.remote is not respected at all for remote selection with
"matching". It is used only when combined with branch.*.merge,
which means that only the "upstream" mode would use it.
I advocated (1) in my previous message, but I would also be OK with (2),
even though it is a change from the current behavior. But what you are
suggesting seems like an inconsistent mix of the two.
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.
So I think what you are getting at is that branch.*.remote is about
saying "when we push X, it goes to remote Y". And with v1.2.3, we
obviously cannot have such a hint, because it is not a branch. But my
point is that is _not_ how it works today. So if you want consistency,
we would also need to adjust how branch.*.remote interacts with
"matching".
-Peff