- 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.
- remove all places we check the flag so it's a no-op now
- flip the messaging to refer to `HOMEBREW_NO_INSTALL_FROM_API` where
relevant
- adjust the documentation
- Use `HOMEBREW_CASK_REPOSITORY` more consistently
- Skip auto-updating homebrew-core for `HOMEBREW_DEVELOPER` too (without
explicit `brew update`)
- Also skip auto-updating homebrew-cask
This allows HOMEBREW_INSTALL_FROM_API functionality to be disabled and will stick around once
HOMEBREW_INSTALL_FROM_API is made the default behaviour.
Co-authored-by: Eric Knibbe <enk3@outlook.com>
Otherwise, a global `core.symlinks = false` setting, likely in a WSL context, breaks Aliases and any other places that use symlinks.
Also enforce consistency in `git config` settings across instances.
Ref: https://github.com/Homebrew/homebrew-core/issues/112539
Git's fsmonitor daemon will prevent our update lock file from being
released if it is running before a `brew update`.
Let's fix that by stopping it whenever necessary so our update lock is
released upon completion.
Fixes#13521.
- Rename use of "preinstall" to "auto update". The original "preinstall"
naming came from the fact that we used to only auto-update before
`brew install` but now that it's many commands: this is more confusing
than useful.
- Add `HOMEBREW_NO_UPDATE_REPORT_ONLY_INSTALLED` and remove
`HOMEBREW_UPDATE_REPORT_ONLY_INSTALLED`; the latter is now the default
and the prior provides an opt-out for better output, performance and
avoiding reading potentially untrusted formulae.
- Add `HOMEBREW_UPDATE_FORMULA_VERSION_CHECKS` and don't check formula
versions by default for better performance by default.
Co-authored-by: Eric Knibbe <3324775+EricFromCanada@users.noreply.github.com>
Co-authored-by: Sam Ford <1584702+samford@users.noreply.github.com>
Current situation with update.sh & update-reset.sh:
Upon creating a new tap and before adding remote 'origin' to it,
running `brew update` produces multiple cryptic error messages.
This change converts these cryptic Git messages into clear warnings
about absent remote 'origin'.
How to test:
1. Create a new tap using `brew tap-new`
2. Run `brew update`
This allows specifying the path of an SSH config file that Homebrew should use instead of the default, `~/.ssh/config`, when fetching Git repos over SSH.
- Only for HOMEBREW_DEVELOPER
- Except for HOMEBREW_CORE_MERGE_MAINTAINER
- Except for GitHub Actions CI
Co-authored-by: Rylan Polster <rslpolster@gmail.com>
Co-authored-by: Mike McQuaid <mike@mikemcquaid.com>