`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.
With "hub checkout" you had to write the complete URL to the PR, which
made it possible to type the wrong owner/repo there. This check covers
that case.
Nowadays, when you only enter the PR number you can't mess up that way
any more, and this test lacks meaning.
Allows the user to choose the remote name for their fork instead of
always using their GitHub username. This is useful for workflows where
folks name the remote for their private fork origin `origin` and
the upstream repo remote is named `upstream`. We happen to use this
workflow at work, because it makes the remote names more predictable and
easy to manage (you always push your new commits to `origin` rather than
a remote name that is dependent on your username).
```
$ git remote -v
upstream git@github.com:github/hub (fetch)
upstream git@github.com:github/hub (push)
$ ./bin/hub fork --remote-name=origin
Updating origin
From ssh://github.com/github/hub
* [new branch] 1.11-stable -> origin/1.11-stable
* [new branch] 1.12-stable -> origin/1.12-stable
* [new branch] 2.2-stable -> origin/2.2-stable
* [new branch] code-coverage -> origin/code-coverage
* [new branch] gh-pages -> origin/gh-pages
* [new branch] master -> origin/master
* [new branch] travis-packages -> origin/travis-packages
new remote: origin
$ git remote -v
origin git@github.com:msabramo/hub.git (fetch)
origin git@github.com:msabramo/hub.git (push)
upstream git@github.com:github/hub (fetch)
upstream git@github.com:github/hub (push)
```
I haven't written tests yet, but I can if this is a feature that the
maintainers are amenable to merging...
When checking out a pull request that doesn't match an existing remote,
this sets the branch's remote and merge configuration fields. If the
pull request is modifiable by the maintainer, it uses the SSH URL to
that you can push to the pull request.
Mislav Marohnić
Josh Betz
Pepper Lebeck-Jobe
Tomas Varneckas
Johan Walles
Marc Abramowitz
Pocket7878
Juan Ignacio Donoso
Sean Allred
Natalie Weizenbaum
Natalie Weizenbaum
Michihito Shigemura
Tomas Edwardsson