This removes sensitivity to the BROWSER environment variable in tests
and makes it easier to verify the URL that the browser was invoked with
without having to stub sub-processes.
This keeps git operations working even when PATH is modified, e.g. `brew
update` will work even though Homebrew runs the command explicitly
without `/usr/local/bin` in PATH.
Additionally, this inserts a blank value for `credential.*.helper` to
instruct git to ignore previously configured credential helpers, i.e.
those that might have been set up in system configuration files. We do
this because otherwise, git will store the credential obtained from gh
in every other credential helper in the chain, which we want to avoid.
Before:
git config --global credential.https://github.com.helper '!gh auth git-credential'
After:
git config --global credential.https://github.com.helper ''
git config --global --add credential.https://github.com.helper '!/path/to/gh auth git-credential'
* Respect system/user timezone in API requests
* Fall back to a known timezone if TZ is not set
Co-authored-by: Cristian Dominguez <cristiand391@users.noreply.github.com>
Adding GITHUB_TOKEN & GITHUB_ENTERPRISE_TOKEN support orthogonal to
Config was getting out of hand, especially in `auth` commands that
adjust their messaging and error status based on the presence of these
environment variables.
The new approach builds in support for tokens from environment straight
into Config object by composition. Thus, commands need not ever be
concerned with any specific environment variables.
Due to our HTTP client default behavior, an `Accept` header is added to
all API requests. This is fine for all commands except `gh api`, where
the user should ideally have fine-grained control over most aspects of
HTTP requests and where there should be little to no defaults in general.
This ensures that while having git remotes to point to either
`github.com` or authenticated GHE instances, adding another git remote
pointing to an unrelated host won't change the remote resolution in any
way, even if the unrelated remote is called `upstream` or `github` (and
thus normally took precedence).
