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