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.
From git documentation:
-C <path> : Run as if git was started in <path> instead of the
current working directory. When multiple -C options are
given, each subsequent non-absolute -C <path> is
interpreted relative to the preceding -C <path>.
We correctly forwarded the `-C <path>` values as git global flags to git
invocations such as `git rev-parse --git-dir`, but that command is
designed to return the result as a relative path to the value computed
from `-C`. This adds an extra step to transform this relative path to an
absolute one by applying values of `-C` as the base directory.
Mislav Marohnić
Rex Schrader
James Ko
Keenan Brock
Parker Moore
Madhusudan.C.S
Heitor Tashiro Sergent