Duy Nguyen wrote:
> On Tue, Mar 19, 2013 at 12:08 AM, Jeff King <p...@peff.net> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to