Duy Nguyen wrote: > On Tue, Mar 19, 2013 at 12:08 AM, Jeff King <peff@xxxxxxxx> wrote: >>> Is there a reason for the remote not being optional, or are we just >>> waiting for a patch? The only problem I can foresee is very minor: >>> there is a ref with the same name as a remote; in this case, we'd have >>> to specify both the remote and the ref. >> >> I think the ambiguity is a little more complex than that, because we >> cannot enumerate the universe of all remotes. Keep in mind that we can >> take either a configured remote or a URL (or ssh host). So what does: >> >> git push foo:bar >> >> mean? Is it pushing "refs/heads/foo" to "refs/heads/bar" on "origin"? Or >> is it using the default refspecs to push to the "bar" repo on the host >> "foo" over ssh? >> >> So you would need some heuristics based on whether something was a valid >> refspec, or could be a valid remote name or URL. > > Assume that we agree on what remote is implied, we could simplify > parsing by specifying the remote with "." (or something short and > unambiguous). So the above command would become > > git push . foo:bar A URL may be a path to a git repository, and '.' is a valid path. Currently, 'git push .' seems to push to the current repository (what does that even mean?). For something truly unambiguous, we'll have to use a character that's disallowed in URLs and isn't interpreted by the shell- I can't seem to think of one. Otherwise, we'll have to fallback to using heuristics anyway. -- 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