Jonathan Nieder [off-list ref] writes:
Junio C Hamano wrote:
quoted
And I think now I agree that indeed is a sensible assumption. I am
not sure '-' is a good token for that, but I do not offhand think of
a reason why '-' would be a _bad_ token for that, either.
Random idea: today you can do
git push origin master; # push branch master to remote origin
git push --multiple origin korg; # push default refspec to 2 remotes
How about:
git push origin korg -- master; # push master to 2 remotes
For this to be any useful, origin and korg has to have the same or
at least similar ref structure, such that pushing my 'master' to
their 'master' makes sense for both sites. I am not sure how common
it would be. If people commonly do so, the above looks like a
reasonably useful feature.
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.
git push origin -- master; # push master to origin, more explicitly
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"?
All of the above sounds a bit too complicated to explain to end
users, but I think they are internally consistent.
git push host:some/path; # ambiguous argument. Please disambiguate.
git push host:some/path --; # push default refspec over SSH
git push -- host:some/path; # push specified refspec to default remote
OK.
git push origin; # is a remote name and not a refname. Good.
git push master; # is a ref name and not a remote name. Good.
Hmm, I dunno.
What do you think?
Jonathan
On Tue, Apr 09, 2013 at 06:19:01PM -0700, Junio C Hamano wrote:
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.
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).
quoted
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