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
More majordomo info at

Reply via email to