On Wed, Apr 10, 2013 at 09:37:01AM -0700, Junio C Hamano wrote:
> > 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
--
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