For compatibility with git, `hub help checkout` will display the help
for git-checkout and there will be no information about hub extensions
to this command.
Now with `hub help hub-checkout`, hub will print the help text from
hub's extension to git-checkout.
- No more `c.Short` property. Instead, the first line of `c.Long`
property is considered a short command description.
- The `c.Usage` text can now contain multiple lines.
- The new `c.Synopsis()` method renders usage synopsis for humans:
Usage: hub my-command --arg
hub my-command --alternative-arg
- The new `c.HelpText()` method renders synopsis + full help text.
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"
In instances where the `SHELL` environment variable is not set, nor is the `-s` parameter set it is not clear what action should occur. Clarify the error message to make it obvious.
Closes#1065
Untested.
setx will automatically truncate the PATH to 1024 characters if it is longer than that. It also mixes the local user's path with the machine-wide path, which is no good.
Unfortunately, the only way around this is running PowerShell to set the PATH manually.
Related link: http://superuser.com/questions/387619/overcoming-the-1024-character-limit-with-setx
It is a common practice to set the push URL of the "upstream" repository to an
invalid URL to avoid accidentally pushing to upstream instead of a fork. The
trouble with the current approach of obtaining remote URLs is that, the URL
obtained for a remote might not be the valid one, even though a valid remote
fetch URL exists. For example, git remote -v might return the following output
~$ git remote -v
origin https://github.com/owner/project.git (fetch)
origin https://github.com/owner/project.git (push)
upstream https://github.com/main/project.git (fetch)
upstream no_push (push)
But github.Remotes() currently parses both these URLs but stores only one of
them, the one that comes the last in git remote -v output, for a given remote.
So in this example, the URL for upstream remote might end up to be "no_push"
instead of https://github.com/main/project.git. This causes problems
downstream. For example, pull-request can't proceed with non github.com URLs
and the command fails even when a valid fetch URL for upstream is defined.
This commit fixes the problem by parsing and storing both fetch and push URLs
for each remote. So later, wherever the URLs are required, we can either
look at fetch URL or push URL or both depending on what is required.
Fixes one part of issue #876. Still doesn't recognize "git+ssh" protocol
scheme.
Mislav Marohnić
James Ko
Rex Schrader
Keenan Brock
Parker Moore
Madhusudan.C.S