This only affects CI builds in cases when the bundle is not cached.

Fixes test failures with Boxen git 1.8.2-boxen1

They emit Ruby warnings on Ruby 2.1.0

Fixes #466

This is required on systems like Exherbo where installation is first
done in a sandbox.

Closes #458

Keeps unversioned files that I'm currently experimenting with from
accidentally getting released.

We can stop pretending that you could run the test suite if you just
obtained the gem. You'd need the Gemfile for that, and the whole
Cucumber suite as well.

Each hub invocation would previously shell out twice to `git remote`:
1. Once to get the list of available remote names
2. A second time to obtain remote URLs with `remote -v`

With the new approach, we get the list of available remotes and collect
their URLs in the same pass. This is part of an effort to reduce the
number of shelling out to git if not absolutely necessary.

In cukes, we use Aruba which uses ChildProcess to handle spawning of hub
processes in tests. It uses Tempfile to create file descriptors with
which stdout and stderr streams are collected from the child process.

However, when hub finished with an `exec`, the stderr in one test would
be mysteriously blank in Ruby 1.8. I tracked that down to being an issue
of Ruby not flushing STDERR output to the stream (really a Tempfile in
the context of tests). https://travis-ci.org/github/hub/jobs/15965636

This hopes to fix the tests, but shouldn't change anything about how hub
operates normally when invoked directly.

Assume that the default branch ref is stored in the file located at
`.git/refs/remotes/origin/HEAD`

This is part of the effort to reduce the number of shelling out to git
in a single invocation of hub if a more direct alternative is available.

We presume that if "origin/master" ref exists, that means this file
represents it: `.git/refs/remotes/origin/master`.

This is part of the effort to reduce the number of shelling out to git
if an alternative, more direct approach is available.

This operates on a presumption that `.git/HEAD` will be in this format
when currently on a checked-out branch:

    ref: refs/heads/master

This change is part of the effort to reduce the number of shelling out
to git in a single invocation of hub.

Shelling out to `git`, which by itself takes ~6ms, used to consistently
take 8-11ms in hub. Due to the number of different data we have to
collect from git, this overhead is the leading cause of slow execution.

Turns out, when we don't use shell redirection, but silence STDERR
ourselves in Ruby, this overhead is gone and the time spent shelling out
is much closer to git execution time.

For speed, we want to reduce the number of shelling out to git in a
single invocation of hub, and reading from "hub.host" is unnecessary if
the current hostname matches the default host ("github.com"), which is
the most common case.

Assume that "github.com" is not an ssh alias to anywhere else. This
optimizes the most common case in which all remotes in a repository
point to "github.com" in their URLs and in which we can avoid
instantiating SshConfig altogether.

A lot of hub execution time was spent in SshConfig, which was a
reasonably compatible reader implementation for the format described in
ssh_config(5). However, all we ever used this functionality for is
resolving hostname aliases the same way `ssh` on the command-line does.
See 4b57f61e

To speed up hub, this strips SshConfig feature set down to a bare
minimum to keep the original functionality:

- Don't record all configuration keys, just "HostName"
- Drop support for the "key=value" assignment syntax
- Drop support for hostname patterns, including "*" to match any value

Not sure how CI ever worked without them, but now it started failing:
https://travis-ci.org/github/hub/builds/15945780

[ci skip]

Broken by 06999d90

[ci skip]

YAML will typically output plain strings, but if they match a reserved
keyword or are comprised of digits, they will be quoted. For
compatibility with existing configurations, strip single quotes from all
values read, since we only deal with string values for now.

Fixes #421

Since cloning of private repos over `git:` protocol is not possible,
users were required to manually add the `-p` flag to trigger cloning
over the `ssh:` protocol.

Now, use the GitHub API to obtain information about the repo to be
cloned, and automatically use the `ssh:` protocol if the repo is private
or if the current user has push access to that repo.

Fixes #212, fixes #213

It's not guaranteed that every git remote corresponds to a valid GitHub
project.

In hub lingo, "origin remote" is the remote pointing to the canonical
GitHub project, i.e. where pull requests should be sent. "Remote branch"
is where hub guesses the user has pushed their changes from the current
local branch.

The origin remote can now be called "upstream", "github", or "origin",
in that order of precedence.

The `browse`, `compare`, and especially `pull-request` commands need to
know the remote branch. Previously we relied on git upstream
configuration, but that wasn't enough. This behavior is now only kept if
git "push.default" is set to "upstream" or "tracking".

For "push.default" values "current", "simple" (git 2.0 default), or
"matching" (git 1.x default), we can safely assume that the user
probably pushes to the same-named branches on some remote, and we ignore
upstream configuration.

To find the remote where the user pushed their changes, we search for
the same-named branch on:

1. the remote which points to a GitHub project owned by the current user;
2. "origin", "github", and "upstream" remotes.

When a match is found, it is assumed that the user pushed there and it
is taken as the implicit pull-request head.

Fixes #158, fixes #360, fixes #381

This feature is likely to get dropped from GitHub API in the near
future. The alternative is to simply create a new pull-request and
reference the original issue in the description.

Every API request will now declare that it wants v3 by setting
"Accept: application/vnd.github.v3+json".

http://developer.github.com/v3/media/

When building hub from a git repository, the detailed version
information will get built into the executable courtesy of
`git describe --tags`. However, if tags are not available in the
git repo--for instance, in the case of Homebrew install from git--this
at least embeds the current SHA in version information.

Loading FileUtils can take more than 10 ms on Ruby 2.0.0, making the
require extremely wasteful for the purpose of just using a single method.

Due to its sheer size, requiring YAML takes ~21 ms on Ruby 2.0.0. To
handle hub's very simple config format, we won't need most of YAML's
features, so we can afford to reimplement YAML just for the syntax we
need to support the existing config format.