'hub issue labels' makes more semantic sense to retrieve all
available labels from the issue tracker. The command 'label'
sounds like the imperative form, i.e. to label an issue.
If the result limit is N, the default `per_page` will be `N + N/2`
instead of the default 100. This aims to achieve faster API requests for
relatively low values of N.
This is to avoid having a writeable fork added with `git://` protocol
(the default when `hub.protocol` is not configured).
This matches the behavior of `hub clone`.
Ignore all lines that are printed before the first command prompt. On
some systems bash prints a message about how to use the sudo command
when started with a clean `HOME`, causing some tests to fail.
Fixes#1477
According to the discussion on #1545 we want to have as few top-level
hub commands as possible to reduce the chances of colliding with
exisitng aliases or commands which may be added to git in the future.
Also, the label listing and modification functionality is not likely
to be used very often, so we shouldn't give the set of commands for
interacting with labels the status of a top-level command.
`git rev-parse --show-toplevel` returns an empty string with success
status when inside a bare git repo.
This avoids the go crash and also tweaks `hub issue` and `hub
pull-request` to work even if current working directory name couldn't be
obtained because it's only used for looking up issue/PR templates, which
isn't critical functionality.
Fixes https://github.com/github/hub/issues/1331
The only thing that has substansively changed is that Go 1.8 handles
redirect logic more safely than previous versions. This means we can
drop our special handling to avoid following redirects to other
domains. We were only doing that to protect against the possibility
of leaking auth headers. With Go 1.8, the auth headers are not
forwarded when following a redirect to another domain, so we don't
need our special handling any more.
As long as people are attempting to build with the Makefile, the new
check_go_version script should cause the build to stop if our
collaborators aren't using at least version 1.8 of go.
However my git installation was run, it installed the
git-completion.{bash,zsh} scripts under
"${GIT_PREFIX}/contrib/completion/" instead of any of the paths that
this test case was expecting.
To make matters worse, the only way to know that this was the problem
was that each scenaro failed with a message about timing out while
waiting for completion to happen in tmux. Just in case there are
other paths out there where the git-distributed completion scripts
may live, I've also added some detection logic to raise an exception
during the "Given" clause of the scenario if we cannot find the
git-distributed bash completion scripts in any of the places we're
looking for them. This would have made it a lot easier to diagonse
the failures.
Before this change, the `pu` would sometimes expand to `pull
pull-request push` if the order isn't important, we should take this
fix.
However, if the order is important, we should probably switch the
expectation such that the options are presented alphabetically as
observed.
Mislav Marohnić
Darren Wee
Michael Kaiser
Pepper Lebeck-Jobe
Elliott Beach
Josh Betz