This is usually "master" but for e.g. git-flow projects it's "develop".
GitHub has an API field for the default branch but I avoided having to
hit the API and instead read from the "head" of the origin remote.

  git rev-parse --symbolic-full-name origin
  #=> refs/remotes/origin/develop

The "head" of the remote seems to be set at clone time by default, and
can be manually set with:

  git remote set-head origin develop

The pull-request command now detects this and sets the default branch as
the pull request base instead of always assuming "master" at origin.

Fixes #154, closes #326

Hopefully solves random test failures:
https://travis-ci.org/github/hub/jobs/9030244

Instruct it to fail on Ruby syntax warnings coming from only the code in
this project.

https://github.com/cucumber/aruba/pull/150

MRI 1.8.6 should be supported by hub, but it's not supported by Travis
anymore.

Each scenario tagged @completion opens an interactive shell in the
background which it drives via tmux. It sends keystrokes to it including
the Tab character and then inspect the contents of the terminal for
changes.

zsh completions are tested against the zsh-distributed git completions
(better quality) and against git-distributed git completions (lower
quality; installed by Homebrew by default).

While exploring the bash-based completion script for zsh, I initially
implemented this so that the bash script would see the new commands.
Obviously this didn't work because the completion script invokes the
real `git` command, not `hub`.  But I think the feature is nice for
users.

This `_hub` completion script should correctly wrap modern versions of
the `_git` scripts distributed by both zsh (native) and git
(bash-based).  The bash-based version could use a bit more love to
complete arguments to the actual subcommands.  Right now it can only
complete the names of the subcommands themselves.

The `compdef` that was previously emitted by `hub alias -s` prevents the
new `_git` script from working, so it has been eliminated.

Fixes #231

Prior to a53f0289, hub didn't clean up PULLREQ_EDITMSG files after a successful
pull request. When people upgrade to the new version of hub which reuses PR
messages, these leftover files will get reused when opening new PRs and will
lead to confusion. The hackish solution is to ignore PULLREQ_EDITMSG files that
are older than the hub ruby script on disk.

Fixes #342

fixes #339

This is a guard against enountering any potentially blocking commands

Making empty commits in tests blocked by opening the default text
editor, waiting for a message which we specified to be empty.

http://thread.gmane.org/gmane.comp.version-control.git/225529

if your branch name contains some characters that are significant to
uri's, then `hub browse` sends you to a 404 page. this change uses
`CGI.escape` to properly encode that when constructing the URL.

an example of where this is a problem is if you use topic branches named
by issues stored in an issue tracker, i.e. `fix-something-#123`
indicating what you're working on and the corresponding issue number.

The cukes cover the same funtionality