Re: [ITCH] Specify refspec without remote

[Jeff King <peff@peff.net>]

On Tue, Apr 09, 2013 at 04:13:32PM -0700, Jonathan Nieder wrote:

> 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

Can we do "git push --multiple" today? My git does not seem to know
about that (and I don't remember any patches in the area). Am I missing
something?

> How about:
> 
> 	git push origin korg -- master; # push master to 2 remotes
> 	git push -- master next; # push two refs to default remote
> 	git push origin -- master; # push master to origin, more explicitly
> 	git push origin korg --; # push default refspec to 2 remotes, again

I like that _way_ better than the "-" proposal. Rather than introducing
a magic token for "the default ref", it fixes the actual syntax problem
(that we have two lists of arguments to the command, and we do not know
where one begins and the other ends). And it does it the same way as
other parts of git.

> 	git push host:some/path; # ambiguous argument. Please disambiguate.

This is a regression.  I thought the point of this exercise was to leave
that working. We could just as easily switch to:

  git push --remote=host:some/path

if we are willing to break the existing syntax. Though your proposal
does have the benefit of breaking only one particular syntax which is
(I'm guessing) less frequently used. But we'd still need the usual
deprecation period, I think.

> 	git push host:some/path --; # push default refspec over SSH
> 	git push -- host:some/path; # push specified refspec to default remote

I like this.

> 	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.

And this is sensible, too.

-Peff