- 24 1月, 2014 1 次提交
-
-
由 Ivan Tse 提交于
-
- 23 1月, 2014 1 次提交
-
-
由 Ivan Tse 提交于
Forking through GitHub's API is asynchronous so there is really no way of knowning when you can access git objects without polling. Alternatively, we can establish the state of the fork with its remote tracking branches and tags by fetching from the "origin" remote and then changing the remote url to the fork.
-
- 19 1月, 2014 8 次提交
-
-
由 Ivan Tse 提交于
Avoids the issue where leading empty lines would result in an empty pull request title. Fixes #439, closes #465
-
由 Mislav Marohnić 提交于
-
由 Mislav Marohnić 提交于
-
由 Mislav Marohnić 提交于
This only affects CI builds in cases when the bundle is not cached.
-
由 Mislav Marohnić 提交于
Fixes test failures with Boxen git 1.8.2-boxen1
-
由 Mislav Marohnić 提交于
They emit Ruby warnings on Ruby 2.1.0
-
由 Mislav Marohnić 提交于
Fixes #466
-
由 Nicolas Braud-Santoni 提交于
This is required on systems like Exherbo where installation is first done in a sandbox. Closes #458
-
- 26 12月, 2013 14 次提交
-
-
由 Mislav Marohnić 提交于
-
由 Mislav Marohnić 提交于
Keeps unversioned files that I'm currently experimenting with from accidentally getting released.
-
由 Mislav Marohnić 提交于
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.
-
由 Mislav Marohnić 提交于
-
由 Mislav Marohnić 提交于
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.
-
由 Mislav Marohnić 提交于
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.
-
由 Mislav Marohnić 提交于
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.
-
由 Mislav Marohnić 提交于
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.
-
由 Mislav Marohnić 提交于
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.
-
由 Mislav Marohnić 提交于
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.
-
由 Mislav Marohnić 提交于
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.
-
由 Mislav Marohnić 提交于
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.
-
由 Mislav Marohnić 提交于
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
-
由 Mislav Marohnić 提交于
Not sure how CI ever worked without them, but now it started failing: https://travis-ci.org/github/hub/builds/15945780
-
- 25 12月, 2013 1 次提交
-
-
由 Mislav Marohnić 提交于
-
- 22 12月, 2013 14 次提交
-
-
由 Mislav Marohnić 提交于
[ci skip]
-
由 Mislav Marohnić 提交于
-
由 Mislav Marohnić 提交于
-
由 Mislav Marohnić 提交于
-
由 Mislav Marohnić 提交于
Broken by 06999d90
-
由 Mislav Marohnić 提交于
[ci skip]
-
由 Mislav Marohnić 提交于
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.
-
由 Mislav Marohnić 提交于
Fixes #421
-
由 Mislav Marohnić 提交于
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
-
由 Mislav Marohnić 提交于
It's not guaranteed that every git remote corresponds to a valid GitHub project.
-
由 Mislav Marohnić 提交于
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
-
由 Mislav Marohnić 提交于
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.
-
由 Mislav Marohnić 提交于
-
由 Mislav Marohnić 提交于
Every API request will now declare that it wants v3 by setting "Accept: application/vnd.github.v3+json". http://developer.github.com/v3/media/
-
- 20 12月, 2013 1 次提交
-
-
由 Mislav Marohnić 提交于
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.
-