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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
