`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
It wraps functionality already provided by "hub checkout". The advantage
with "hub review" are twofold:
* Discoverability. It wasn't until I started browsing the hub source
code that I realized this functionality was present.
* Usability. Just typing the PR number is easier than having to figure
out its URL.
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...
This change adds a long-form flag `--show-pulls` to `hub issue` that
directs hub to include pull requests in the issue listing. The
default value is false; the default behavior does not change.
Temporary fix until a better abstraction for pull requests can be
designed.
Related: #1303
Related: vermiculus/magithub#44
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.
We might bring back the self-updater at some point, but right now it's
dead code and it's not clear to me how to implement it in a fashion
where it also updates dependent files such as shell completion scripts
and man pages.
To mirror all the other `hub release` commands, allow the user to delete
releases from the command line. The new subcommand takes only one
argument (the tag of the release being deleted).
Fixes#1326