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.
If we're installing from the API: we cannot use Git to check for differences in
packages so instead use `{formula,cask}_names.txt` to do so.
The first time this runs: we won't yet have a base state
(`{formula,cask}_names.before.txt`) to compare against so we don't output
anything and just copy the files for next time.
Previously, we required all formulae and casks to be in a specific
formula or cask directory but did not check any subdirectories.
This commit allows using subdirectories for official taps, the only
ones likely to be big enough to warrant sharding in this way and to
avoid potentially breaking backwards compatibility for existing taps.
This was inspired by the most recent issues with homebrew-cask.
- These are arbitrary length limits that had a load of disables in code.
- The limits were only increasing over time rather than decreasing.
- Fixing the problematic code to be shorter would take a long time for
questionable gain since the problem has been around so long.
- We're not going to make the really long things be any shorter any time soon.
- The instructions in issue 14685 say, pragmatically, "disable all the rubocop
rules we're never going to realistically fix e.g. Metrics/ClassLength". But
that felt like a slippery slope to more _really_ long modules/classes/blocks,
and the limits are here for a reason.
We warn sometimes when we tell people to build from source and it's
not supported but we don't actually warn non-developers when invoking
the various install commands so: let's start doing so.
While we're here, also update the existing messaging to reflect the fact
we're on Mastodon now too and we don't want maintainers being
individually bothered about errors either.
I've tried to balance having messages here vs. having them be so long
at the beginning of installation that they will be missed or be overly
obnoxious.
