Due to limitations of `hub fork` in hub 2.2, scripts had to repeat the
command at least two times; the 2nd time was to read the fork name from
the "fatal: remote MYNAME already exists" message output from git.
In upcoming hub 2.3, the `hub fork` command is improved to always output
the remote name, regardless of whether one already existed or not. With
this approach, only one `hub fork` call will ever be necessary when hub
is up to date.
We first search for gtar in PATH, then
check if Homebrew's gtar is available,
then finally search for tar in PATH.
Signed-off-by: Bob W. Hogg <rwhogg@linux.com>
Creating a fork and pushing to it doesn't work when the repository in
question is a shallow clone. By default, Homebrew clones all taps in
shallow mode unless `--full` was passed or $HOMEBREW_DEVELOPER was set.
Reduce the chance of false flagging by making sure that the existing pr
surfaced by GitHub.issues_for_formula actually contains the exact formula name
in its title.
Previously, old mirrors are only removed if the requested spec is
stable, and if the mirror lines only have two leading spaces. This leads
to stale mirror line(s) when the formula a stable block like
stable do
url "http://example.com/v1.0.tar.gz"
mirror "http://example.net/v1.0.tar.gz"
end
where the mirror line is lead by four spaces.
In this commit, we discard the /(^ mirror .*\n)?/ pattern, and instead
create a pattern with the exact url and flexible leading spaces for each
mirror of the requested spec.
When a --version is specified, use this specified version in the name of
the downloaded file rather than the default that is parsed from the URL.
For instance,
brew bump-formula-pr --devel \
--url=http://www.zsh.org/pub/development/zsh-5.2-test-2.tar.gz \
--version=5.2-test-2 zsh
should download to $HOMEBREW_CACHE/zsh-5.2-test-2.tar.gz (correct
behavior after this commit) rather than
$HOMEBREW_CACHE/zsh-2.tar.gz (wrong behavior before this commit).
After branching, bumping, pushing, and pr-ing; return to whatever branch
was originally checked out.
In most cases, I'd imagine users to want to continue receiving tap
updates from master. However, after using bump-formula-pr, the tap in
which the formula was bumped is left on the working branch that was
doing the bumping and pull-request. After opening the PR, we should
return to whatever branch the user originally had checked out – most
likely master. (But git allows us to just say "previous branch" by using
`-`)
Without `--no-track`, some git setups may automatically set
`origin/master` as the tracked upstream for the newly created branch.
This upstream is what hub defaults as --head when opening PRs. By not
allowing git to set `origin/master` as upstream, hub can then use the
proper --head for the PR.
Since hub still needs to know what --head is intended to be, we can set
the branch's upstream when pushing: with the --set-upstream option.
Fixes#755
`any?` is not the opposite of `empty?`. Besides the case that
`[false, nil].any?` will return false, `any?`(O(n)) has much worse
performance than `empty?`(O(1)).
If we're bumping the formula's stable version, then we also must reset
the formula revision to zero.
Note that if and only if a revision is being removed, this commit will
enforce the convention that there should be a blank line before a simple
head spec if and only if there is a formula revision. Any preexisting
violation of the convention (in particular, a blank line before a simple
head spec in the absence of a formula revision) won't be proactively
corrected since we'd not be removing a formula revision in that case.
Closes#369.
Signed-off-by: ilovezfs <ilovezfs@icloud.com>
- simulate version change for dry-run
- make sure we're using :devel version if called with --devel
Closes#318.
Signed-off-by: ilovezfs <ilovezfs@icloud.com>
Add a new developer command (i.e. requires `HOMEBREW_DEVELOPER` set in
your environment) to bump the version of a formula and create a new pull
request with the new version.
ClosesHomebrew/homebrew#49848.
