This should allow any repositories that change from `master` to `main`
to be automatically migrated by `brew update` without requiring manual
intervention or displaying errors to the user.
I accidentally typed `brew update --greedy` instead of `brew upgrade --greedy` and got some strange output.
This fix causes unrecognized long options to throw a usage message and exit like all the other subcommands.
Before:
```
% brew update --greedy
==> Updating Homebrew...
Usage: brew update-report [--auto-update] [--force]
The Ruby implementation of brew update. Never called manually.
[...]
```
After:
```
% brew update --greedy
Error: Unrecognized option '--greedy'
Usage: brew update, up [options]
Fetch the newest version of Homebrew and all formulae from GitHub using git(1)
and perform any necessary migrations.
[...]
```
Checking for `HOMEBREW_NO_INSTALL_CLEANUP` was added in #18825, but this
breaks developers by switching them to the stable branch.
Setting `HOMEBREW_NO_UPDATE_CLEANUP` when `HOMEBREW_NO_INSTALL_CLEANUP`
is set seems like a relatively recent addition, so I don't think it
hurts to just remove it. We can add it back (correctly) if there are
users that need it.
- Output a message every time auto-update is run rather than a 3 second
timer. This makes it more obvious that Homebrew isn't just sitting
doing nothing for 2.9 seconds.
- Output a message when running `brew update` so Homebrew doesn't just
sit there silently doing nothing.
- Update all taps when `brew update` is run, not just those hosted on
GitHub. This makes it more obvious that people don't need to explictly
run `brew update` "just in case".
- As a result of this, remove `brew tap --force-auto-update` as it's no
longer necessary.
If you're e.g. running Homebrew over `sudo`: shelling out to `whoami`
is less effective than just telling people which user you're running
as when we run the check.
Download the previously stored tap migrations files for homebrew/core
and homebrew/cask from the formulae.brew.sh API.
This adds a much longer stale time (24 hours) to decide whether or not
the migrations files need downloaded from the API in Ruby land.
`brew update` will still update them every time.
Requires https://github.com/Homebrew/brew/pull/15628
Fixes https://github.com/Homebrew/brew/issues/14897
Move the `names*.txt` files even when the file size hasn't changed
(which can happen when the versions change in the API but the file
size doesn't change).
Fixes#15217
While we're here, also add some whitespace for easier reading.
- Make copying to `*_names.before.txt` the responsibility of `update.sh`
(unless the file doesn't exist at all). This provides the added
benefit of allowing the inspection of the before/after state after
running a `brew update` rather than both files always being identical
at this point.
- State `No changes to formulae or casks.` on macOS.
- Rename and flip `updated_formula_report` to `auto_update`; this naming
was confusing every time.
- Only display the `You can upgrade with...` messaging if we're not
auto-updating as sometimes it will be displayed before the commands it
references (e.g. `upgrade`, `outdated` or an `install` that proceeds
to upgrade these formulae).
Fixes https://github.com/Homebrew/brew/issues/15065
We set `core.fsmonitor` to `false` in #13586 because Git's fsmonitor
daemon prevented the release of our locks, resulting in errors for some
users reported in #13521.
However, the fix from #13586 set `core.fsmonitor` to `false` too often.
This is not needed for taps, or when `HOMEBREW_REPOSITORY` is different
from `HOMEBREW_PREFIX`. The issue in #13521 stems from the fsmonitor
daemon preventing the release of our locks, so there is no need to
prevent the daemon from monitoring repositories that don't contain our
lock files.
