Re: [ITCH] Specify refspec without remote

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 10, 2013, 13:19 UTC
Message-ID: <CALkWK0=St08WGD82JqGpW7ZVrtv0RU8=X9kUqzYb+6Jm8X63aw@mail.gmail.com>
In-Reply-To: <20130409231332.GZ30308@google.com>

Jonathan Nieder wrote:

>         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 definitely like the idea of using -- to disambiguate, as it is consistent with existing git commands (that are internally using the rev-list machinery). However, I disagree with the idea of being able to specify multiple remotes: what does 'git push A B -- master +next' mean? Do I know that master and next are present in both A and B? Do I know for certain that a force-push to next won't wipe any data on either A or B accidentally? As the number of remotes and refs increase, the amount of information that the user must know about each of the remotes is simply huge. Therefore, I think it is unnecessarily confusing and unnecessary. Moreover, it can easily be achieved in shell, and there is no advantage to supporting it in push unless we're doing something like a parallel push.

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

Regression.  It should just treat host:some/path as a destination, not a ref.

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

This is what I finally want. With your -- to disambiguate, the logic for doing this has been simplified greatly.