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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html