`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.
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
Since `--push` has just created a new branch, there could be a slight
delay before GitHub registers it, and there's a possibility that a 422
would be returned for the "head" field. If that happens, retry the POST
a couple of times until it either succeeds or times out.
This removes an extra step from the process of publishing a pull
request. It also gives the user a chance to back out of the entire
process by saving an empty pull request message.
The previous implementation fetched refs into `refs/remotes/OWNER/BRANCH`.
Now, fetch `refs/pull/ID/head` directly into FETCH_HEAD and merge that.
It's a more straightforward approach that generates no artefacts.
This is for similarity with the reimplemented `hub checkout` command
which now also uses `refs/pull/ID/head`.
When there is already a git remote for the head repo of a PR to be
checked out, fetch the corresponding branch from that remote instead of
fetching the special `refs/pull/XY/head` ref.
This sets up a pull/push workflow for branches that the user might have
write access to and wishes to collaborate on.
Fixes#1238
Since the test commits are empty and had identical commit messages, two
commits with the same parent could end up having identical SHAs. To
avoid that, generate a unique message for each empty commit.
With the new approach, create a temporary remote, fetch it, and delete
it immediately. Its git objects will still remain to be available for
cherry-picking.
Don't try to default `target_commitish` to the currently checked out
branch. Instead, keep the value blank unless explicitly provided. It
will default to the main branch on the server.
In case when the PR's head and base repositories are the same, check out
the new branch in a way that sets up push workflow to the same branch.
git fetch origin +refs/heads/fixes:refs/remotes/origin/fixes
git checkout -b fixes --track origin/fixes
Now `hub remote` will only prompt to select from your configured hosts
if it can't infer the GitHub hostname from existing remotes.
In case you're prompted, and you choose a GHE host, now that choice will
be properly reflected in the generated URL, unlike before when it would
always revert to "github.com" regardless of choice.
Fixes#1141
When the repo that hosts the `head` for the PR is moved to another
owner, the `owner:branch` specification will be wrong and the GitHub API
will return HTTP 422.
This resolves the latest owner/name pair for head repo so that the value
is never stale when submitting new PR to be created.
Fixes#467
Also, adopt the new name of the fork more precisely so it's reflected in
the new remote URL. The name of the new git remote is for now *not*
inherited from the returned Repository object for backwards compatibility.
Fixes#1178
HTTP client used to automatically follow GET redirects, or turn certain
POST redirects to GET when applicable, but for opening a new pull
request for a renamed repo, we need to repeat the POST against the
updated location.
- `hub issue` now displays color based on issue open/closed state
- `hub issue` no longer displays HTML URL since it was noisy
- `hub issue` no longer lists pull requests
- `hub issue create` tweaks for compatibility with `hub release create`
In `hub clone NAME`, "NAME" was previously considered a local resource
if a directory of the same name existed, and the clone command was left
unchanged.
That worked for a while, but some users were surprised that they
couldn't clone their repo named "NAME", only to discover that there was
an unrelated directory "NAME" in the current working directory.
Also, a git bundle is a valid cloneable resource, but is a file and not
a directory.
This refines the detection of cloneable resources. "NAME" is considered
to be locally cloneable if one of the following is true:
- "NAME/.git" exists
- "NAME" is a bare git repo
- "NAME" is a file whose first line includes "git bundle"
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
Goel
Wesley Bland
Pascal Corpet
Dylan Arbour
Frederick Henderson
James Armes
Glenn Pratt
Dennis Cornwell