Re: [ITCH] Specify refspec without remote

[Jeff King <peff@peff.net>]

On Wed, Apr 10, 2013 at 01:05:12PM -0700, Jonathan Nieder wrote:

> I don't see a big problem here, actually.  What's so wrong with
> branch.<name>.remote affecting what "git push" does?  If
> branch.crazy-feature.remote is my-personal-remote and I run
> 
> 	git push
> 
> and "[push] default = upstream", then it is obvious what the user
> wanted to happen.  But what about when "[push] default = matching"?
> Which of the following behaviors is correct?
> 
>  a) Error: you didn't tell me which remote to push to.
>  b) Just behave like "git push my-personal-remote :".
>  c) Ignore which branch is the current branch and behave like
>     "git push origin :".
> 
> How about when "[push] default = current"?
> 
> Except that people might have scripts or habits tied to the current
> behavior, any of (a), (b), and (c) sounds fine to me.  (b) is the
> obvious choice for historical reasons.

I think (b) could be quite surprising to a user. I suspect it hasn't
come up because people just don't work with a lot of different remotes
in practice.

> Now if I rely on the proposed DWIM and run
> 
> 	git push master
> 
> then the corresponding choices are:
> 
>  a) Error: you didn't tell me which remote to push to.
>  b) Just behave like "git push my-personal-remote master".
>  c) Behave like "git push origin master".
>  
> (b) is not a good choice there, but (a) and (c) look equally fine.

My complaint with anything but (b) is that you can't use a relatively
simple rule ("if you do not specify a remote, we fallback to defaults,
in this order"). Now the rule is different depending on what is in the
refspecs. If I say "git push HEAD", where should it go? Does it respect
branch.*.remote or not?

-Peff