Explicitly setting `hub.protocol` to `git` or using `HUB_PROTOCOL=git`
still uses the `git` protocol.
Co-authored-by: Mislav Marohnić <mislav@github.com>
In `hub clone NAME`, "NAME" was previously considered a local resource
if a directory of the same name existed, and the clone command was left
unchanged.
That worked for a while, but some users were surprised that they
couldn't clone their repo named "NAME", only to discover that there was
an unrelated directory "NAME" in the current working directory.
Also, a git bundle is a valid cloneable resource, but is a file and not
a directory.
This refines the detection of cloneable resources. "NAME" is considered
to be locally cloneable if one of the following is true:
- "NAME/.git" exists
- "NAME" is a bare git repo
- "NAME" is a file whose first line includes "git bundle"
Since cloning of private repos over `git:` protocol is not possible,
users were required to manually add the `-p` flag to trigger cloning
over the `ssh:` protocol.
Now, use the GitHub API to obtain information about the repo to be
cloned, and automatically use the `ssh:` protocol if the repo is private
or if the current user has push access to that repo.
Fixes#212, fixes#213
API authentication and persisting of credentials in Config was
convoluted and inflexible, and it wasn't possible to log in with
different credentials than your GitHub screen name. Since Enterprise
supports different authentication schemes, it's important to allow
emails for login as well (or any string for that matter) and retrieve
the user's screen name after successful authentication.
This also improves handling special characters in Basic Auth usernames
and passwords.
Fixes#407
Austin Ziegler
Mislav Marohnić
Leonardo Pistone
Ethan Zhuang