Use "origin/<base>" and "origin/<head>" for git commit comparison and
summary in the pull request template instead of the local branch
equivalents, since the local branches could be out of date with the
remote tracking branches.
Re-wrapping to 78 chars was dangerous since it could lead to moving
a #-reference to the beginning of a line which would then get
interpreted as a comment.
Wrapping pull request message is not useful anyway since it's Markdown.
For best results when rendered, users should unwrap their text.
Fixes#548, closes#570
If the user's `LANG` environment variable doesn't include "UTF-8", the
default external encoding in Ruby will be US-ASCII and as such, string
operations will fail dealing with pull request message or changelog that
contains non-ASCII characters.
This explicitly configures external encoding in hub to default to "UTF-8".
This applies to data over ARGV, `$stdin.read`, and reading files.
Fixes#566
If someone misspells `--help`, for instance:
git pull-request -help
This aborts the command instead of continuing by interpreting `-help` as
it was the deprecated title argument. Any value that starts with a dash
will abort.
Fixes#460
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.
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.
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
Prior to a53f028, 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.
Emulates the interface of `git commit`:
$ hub pull-request -m "This is my title"
$ hub pull-request -F /path/to/message.txt
$ hub pull-request -F -
The old way of passing in just title is deprecated
$ hub pull-request "Deprecated title"
Fixes#183
- If text editor aborts, message is discarded.
- If the API request to create the PR fails, message is kept.
- If the API request succeeds, message is discarded.
- When kept message is reused for subsequent PR, only its title and
body get inserted. The PR instructions and changelog still get
regenerated.
Fixes#178
The problem was that the dumb JSON generator simply dumped strings with
Ruby's `inspect` method, which on 1.8 generates escape sequences that
are incompatible with JSON.
Now strings are dumped simply as they are, with only a handful
characters escaped (double quote, backslash, whitespace).
Fixes#235
When reading config, "insteadOf" substitution rules aren't applied.
Using `git remote -v` is better because it reports the URLs that would
actually be used by git.
This reverts the feature that supports detecting the GitHub URL among
multiple others made for #59. If you have multiple URLs configured for
the same remote, put the GitHub one first and you'll be fine.
Fixes#241
Mislav Marohnić
Jingwen Owen Ou
Tomas Varneckas
Ivan Tse
Luismi Cavalle