`Formula[name]` gets called with an unqualified name and thus will throw
`TapFormulaAmbiguityError` exceptions (silently ignored) if both the old
and the new tap are present and changes for the new tap are pulled
before the migrated formulae are removed from the old tap.
The result is an empty or incomplete `changed_formulae`, causing issues
with pulling the corresponding bottles and possibly other problems, too.
The "apply" DSL method can be called from patch-do blocks to specify
the paths within an archive of the desired patch files, which will be
applied in the order in which they were supplied to the "apply" calls.
If "apply" isn't used, raise an error whenever the extracted directory
doesn't contain exactly one file.
The "apply" method can be called zero or more times within a patch-do
block with the following syntaxes supported:
apply "single_apply"
apply "multiple_apply_1", "multiple_apply_2"
apply [array_of_apply]
If apply must be used, a single call using the second syntax above is
usually best practice. Each apply leaf should be the relative path to a
specific patch file in the extracted directory.
For example, if extracting this-v123-patches.tar.gz gives you
this-123
this-123/.DS_Store
this-123/LICENSE.txt
this-123/patches
this-123/patches/A.diff
this-123/patches/B.diff
this-123/patches/C.diff
this-123/README.txt
and you want to apply only B.diff and C.diff, then you need to use
"patches/B.diff" and "patches/C.diff" for the lowest-level apply leaves.
The code was provided by Xu Cheng. Any mistakes are mine.
This avoids crashing with an unknown key error, if the GitHub api
response does not contain the ratelimit headers, e.g. when GitHub is
down. It also tries to display the JSON error message in addition to
the HTTP status.
ClosesHomebrew/homebrew#48538.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Both `coreutils` and `findutils` suggest to add `#{opt_libexec}/gnubin`
to PATH in their caveats to get the non-prefixed binaries from those
formulae. Check this in addition to the version-specific directory that
is less likely to be in PATH.
ClosesHomebrew/homebrew#48207.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
* Use git function instead of refreshing bash cache on `git` path.
* Better `which_git`:
* Take user's setting of `HOMEBREW_GIT` and `GIT` env variable into
account.
* Always expand git path.
* Only check Xcode installation for OS X.
ClosesHomebrew/homebrew#48508.
Signed-off-by: Xu Cheng <xucheng@me.com>
* Make sure `.git` directory be deleted at any error. So we won't have a
stale setup.
* Run `git fetch` and `git reset` when initialize git in the first time.
Otherwise, we will get error and merging problem afterwards.
ClosesHomebrew/homebrew#48509.
Signed-off-by: Xu Cheng <xucheng@me.com>
Determine the age of the local `HEAD` first and only if it is older than
24 hours proceed with the much more expensive `git ls-remote` to check
if there are any new upstream commits (there usually will be).
This keeps the overall logic unaltered, but significantly speeds up the
check for users that have recently updated (still slow for all others).
ClosesHomebrew/homebrew#48499.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
Not sure why this is happening (beyond the Chef cookbook stupidly
deciding to not call through `bin/brew`) but fail and print a scary
looking error to hope to point people in the right direction.
ClosesHomebrew/homebrew#48261.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Otherwise Bash can cache a relative PATH and then get upset when it
changes directory and cannot find it any more.
ClosesHomebrew/homebrew#48493.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Also change the logic a bit to iterate over the individual files per
directory, as having a directory without bash commands will otherwise
pass a literal `*.sh` to `bash -n`, causing it to fail.
ClosesHomebrew/homebrew#48323.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
This should help to avoid collisions with external commands and other
shell functions in the future and is closer to what we do in Ruby, where
commands are namespaced by being methods of the `Homebrew` module.
`bin/brew` already sets up a bunch of environment variables. There's no
need to re-export them for external commands. (`HOMEBREW_LIBRARY_PATH`
and `HOMEBREW_CACHE` continue to be determined later in the Ruby code.)
We have asserted before that the 1st argument is the command name. No
need to pass it to the bash command, which will make the argument
handling for the command itself a bit easier.
Remove the executable bit from the file to make it clear it is not
supposed to be executed directly. This should make the shebang line and
the early check also unnecessary.
Commands implemented in shell (bash) are supposed to be sourced from
`bin/bash` instead of being executed directly. Consequently, don't
expect the implementation files to be executable.
Allow people to run this command (so we can ask people to test it)
without having to set `HOMEBREW_DEVELOPER`.
ClosesHomebrew/homebrew#48260.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
* only set HOMEBREW_UPDATE_BEFORE inside pull instead of fetch.
* fix HOMEBREW_UPDATE_BEFORE/AFTER variable settings. They should be set
to INITIAL_REVISION and CURRENT_REVISION correspondingly.
* avoid unnecessary duplicated shellout.
* remove unused variable.
