If you’re using a /usr/local prefix but e.g. /usr/local/homebrew/Cellar
then you’ll miss out on most binary packages for no good reason so warn
people of that.
`Homebrew/>1.0.0 (no git repository) (Macintosh; Intel macOS 10.7.5)...)
reads pretty weirdly in a user agent and I've had complaints that `>`
may be an invalid character in some cases.
For tagged commits produces the output:
- `1.0.1`
For untagged commits with a dirty tree produces the output:
- `1.0.1-19-g23efbc5-dirty`
Performance:
```
git describe --tags --dirty 2> /dev/null
0.07s user 0.01s system 96% cpu 0.086 total
```
This means we can tag any commit without needing to manually remember
to bump the revision every time.
If we have a `brew.sh` which has set
`HOMEBREW_ENABLE_AUTO_UPDATE_MIGRATION` then let's allow an auto-update
migration. That's because it contains the fix below it _before_ the
update happened which means the auto-update won't fail in the same way
as if updating from an old version.
On auto-update `HOMEBREW_LIBRARY` may change location which means that
it won't be found for the actual install command. Look for this having
occurred and then set the new `HOMEBREW_LIBRARY` (and
`HOMEBREW_REPOSITORY`) accordingly.
Not quite a mass replacement as I've used OS X and Mac OS X where
describing specific older versions and added compatibility methods
for things in the DSL.
This seems generally like a good idea given that we're making syntax changes to
formulae & are going to keep doing so for a little while yet. Taps may have moved
over to that syntax, which then causes tap failures if brew isn't up-to-date.
Should fix situations like https://github.com/Homebrew/homebrew-php/issues/3545.
If you're using e.g. a `/usr/local/homebrew` prefix then don't require
the `/usr/local/Cellar` to be manually created to avoid e.g.
`/usr/local/homebrew/Cellar` being used. Let's do all we can to let
people use this `Cellar` location as it means they can put their
repository wherever they like and still use all our bottles.
