This fixes:
fatal: Cannot setup tracking information; starting point 'BRANCH' is not a branch.
if the remote refspec is set up to only fetch specific branches and NOT
like the default `+refs/heads/*:refs/remotes/origin/*`.
I don't understand why would git, after fetching into
`refs/remotes/origin/BRANCH`, complain that `origin/BRANCH` is not a
branch, but there we have it. Setting up upstream tracking manually
works around this problem.
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.
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
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
It is `headRepo.Owner.Login` that holds the unix account name of the
owner, and `headRepo.Owner.Name` is omitted from the embedded owner
information, resulting in the following failure:
```
% hub checkout https://github.com/github/hub/issues/{number}
fatal: '' is not a valid remote name
```
To obtain the owner/fork-name combo, instead of reading it from "label"
field from the PR response simply read from `Head.Ref` and
`Head.Repo.Owner.Name` instead. This is because label is meant to be
human-readable, isn't well-documented in GitHub API docs and is unclear
when it contains two components (delimited by `:`) and when it contains
only one.
`Args.InsertParam` panics about index out of bound if the index is larger than param size. These changes reset the index to param size for such case. This is equivalent to appending new items to the end.
This fixes#812.