If we have a HOMEBREW_REPOSITORY and HOMEBREW_PREFIX mismatch (now the
default) then we can block access to the whole of HOMEBREW_REPOSITORY
rather than just the HOMEBREW_LIBRARY and `.git`.
This reverts commit a124680b189f50ebeb550845e3c0efd34db66247.
Will need to be smarter than this, since people can't force Travis to
update. I'm losing count of the amount of times Travis has forced a change
of plans around Homebrew this year.
Closes https://github.com/Homebrew/brew/issues/1096.
From the 8.1 Xcode Beta:
```
There is no Command Line Tools (OS X 10.11) for Xcode 8 package. Xcode 8 contains
SDKs that are incompatible with earlier toolchains. Developers who want to make
use of the Xcode 8 SDKs from the command line must choose the SDK with `xcode-select`.
Developers on OS X El Capitan who have installed versions of the Command Line Tools
(OS X 10.11) for Xcode 8 Beta should install Command Line Tools (OS X 10.11)
for Xcode 7.3.1.
```
Thanks Apple.
This hack has been in Homebrew Cask for more than two years
(since 51f93e6dc9c3da4ab2118459ea95e45c104386ec), and it originated even
earlier (6d2f7bc55af0b2aa915b2396d213e30a4446256c).
Cask tests apparently aren't even run on Travis anymore,
so this can be safely removed.
This adds a CMake cache entry to std_cmake_args specifying that the
function clock_gettime is not available on 10.11 in order to avoid
runtime errors such as
dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
when the build system is confused by Xcode 8's weak symbols.
Other weak symbols on 10.11, which may merit the same treatment in the
future, can be found with
grep 'weak$os10.11' MacOSX.sdk/usr/lib/system/libsystem_c.tbd
It’ll only get printed for people getting updated to tags now and these
are people who haven’t run a `dev-cmd` so we want to air on the side of
telling them less stuff that will confuse them and assume people who
have manually made another `git` branch will know how to get back to it.
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.
When exactly two versions of a package were installed, the uninstall
message should not read "Remove them all with...", since only one
version remains.
"Remove all versions with..." is flexible enough to avoid being
interpreted as grammatically incorrect, and it still accurately
describes the general behavior of `brew uninstall --force`.
- Don't let the `UPSTREAM_TAG` variable bleed into future repository
checks.
- Even if the tag branch is an ancestor of the tag ensure that it's
forced back to the tag anyway.
Rather than following every change on `master` let’s have non-developer
users (i.e. those who have never run a `dev-cmd` or set
`HOMEBREW_DEVELOPER`) update between tags.
This provides a fairly natural beta (the `master` branch`) and stable
(the tags) approach without restricting us to any particular way of
managing our tags.
