No idea how this was suddenly broken! :/

Attempts to address intermittent "Rack application timed out during boot"
https://travis-ci.org/github/hub/jobs/574770004

Change quotes in Sync command to be consistent with Git style

Fixes #2233.

Remove NC/Nc from pr list formatting

Tweak Makefile to support older Go versions' backported module support

Fix error message on hub --paginate

README: Replace "Linuxbrew" with "Homebrew on macOS or Linux"

Avoid unnecessary conversions

Trap syscall.SIGTERM instead of os.Kill

Fixed ineffectual assignments in tests

Simplify code

Calling hub with one or more options but no subcommand resulted in the
following error message trying to expand an empty string as an alias:

	error: key does not contain variable name: alias.

This fixes the root cause: attempting to retrieve an invalid config key.

- We're (slowly) moving away from the Linuxbrew name, now Linux is
  officially supported.

No need to covert these types.

os.Kill can not be signal trapped. I assume we want to trap syscall.SIGTERM
instead?

Don't assign values we don't end up checking.

- Use bytes.Equal instead of bytes.Compare
- Use time.Since instead of manual timestamp subtracting
- Use sort.Strings instead of sort.StringSlice
- No need to specify the len of the slice

Allow hub used in Actions by specifying GITHUB_USER

When supplied with GITHUB_TOKEN, hub will attempt to request the `user`
API resource which isn't available in the context of Actions.

To work around this, scripts may now set GITHUB_USER to avoid hitting
the unavailable API resource.

Hub is impossible to use from within GitHub Actions because specifying
GITHUB_TOKEN will trigger the code path where the `user` resource is
requested from the GitHub API to get the current login name, but this
resource is not available for that token.

This failure message was cryptic and misleading before as it was
sometimes presented as HTTP 401. This change ensures that the correct
HTTP 403 "Resource not accessible by integration" message is shown.

Improve push target detection for `push.default=upstream`

When `git config push.default` is "upstream" or "tracking", but the
current branch is pushed to a remote without having upstream
configuration set up (for example, via `git push <REMOTE> HEAD` without
`-u`), this change makes it so that the remote tracking branch (the push
target) is still discovered via the same mechanism as if `push.default`
wasn't set (i.e. iterating through all the remotes).

https://github.com/github/hub/issues/189#issuecomment-507639770