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.
I would have assumed the opposite. We feed "push" two items: where to
push (dst), and what refspecs to push (refs). We may or may not have
each item. Here's what's possible today:
dst=present, refs=present: (case 1)
push to $dst, using $refs
dst=present, refs=missing: (case 2)
push to $dst, using refspecs from remote.$dst.push or push.default
dst=missing, refs=missing: (case 3)
push to remote.pushDefault, branch.*.remote, or "origin"; use
refspecs from remote.$x.push or push.default, where $x is the remote
we decide to use.
The missing case 4 is obviously:
dst=missing, refs=present
And I would expect it to select the remote in the same way as case 3. In
other words, the "where" and the "what" are orthogonal, and the presence
or absence of one does not affect how the other is calculated (with the
exception that _if_ we have a configured remote, whether it was
specified by the user or calculated, we may use its config if no
refspecs are specified).
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).
> > git push origin korg --; # push default refspec to 2 remotes, again
>
> As you are _not_ saying what to push, I would expect
> branch.$name.remote may have to come into the picture, but because
> you are saying where to push, that is not the case. What does
> "default refspec" mean in this context? What "git push origin" (no refspecs)
> would push by default will be sent to "origin", and what "git push
> korg" (no refspecs) would push by default will be sent to "korg"?
Yeah, I would expect that each uses its own default refspec. That is,
the above command is exactly equivalent to:
git push origin && git push korg
(possibly without the short-circuit behavior of "&&", but definitely
taking both into account in the exit code).
I'd also be fine if we punted on the multiple remotes thing for now. You
can accomplish it easily in the shell, as I showed above (and it is not
any less efficient, since we have to make two network connections
anyway). Jonathan's syntax allows for 0 to N remotes alongside 0 to N
refspecs. The interesting new case (to me, anyway) is the 0 remotes, >0
refspecs case. But we don't have to handle >1 remotes now; once we have
the syntax in place, we can make it work later when we've decided on the
semantics.
-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