This will be slightly slower if you have a bunch of non-formula (i.e.
command or cask) taps but it avoids the confusion of having Homebrew
saying it's updated when it only did so selectively.
Fixes#1946.
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.
- 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.
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.
Ensure that `brew update` always runs the LinkedKegs migration if needed
as it may not have been run by `brew update` if it was using `--preinstall` or
a `git pull` etc.
Also, if the old paths still exist: just use them instead.
Finally, always try to unlink/unpin before link/pin.
Fixes https://github.com/Homebrew/homebrew-core/issues/4918.
Apple reset this on every OS X major (and some minor) updates and it
always proves a painful and unnecessary step. Instead just check the
directories we actually care about are writable.
This may mean if these directories do not already exist (although they
are now created by the installed) that `brew link` will fail and require
manual intervention but this seems to be superior for both new and the
majority of existing users.
A `git reset --hard` without stashing first risks nuking in-progress
work. A `git reset --mixed` should allow stashing to occur more often
on e.g. merge conflicts.
Fixes#766.
Add a `brew update --force` to side-step all of the clever optimisations
we have to detect if an update is unnecessary. That means if those
optimisations go wrong in future we can tell people just to run this
single command.
This would have been a useful workaround for the issue fixed in 985c672.
UPSTREAM_BRANCH was being used both as a loop variable name and name
for the upstream branch for HOMEBREW_REPOSITORY. This meant that the
variable names were overwritten which prevented update.
Closes#693.
Tweak the logic further to make the no-op case even faster.
Before:
```
brew update 1.10s user 1.05s system 92% cpu 2.325 total
brew update --preinstall 0.60s user 0.77s system 96% cpu 1.433 total
```
After:
```
brew update 0.60s user 0.34s system 83% cpu 1.132 total
brew update --preinstall 0.29s user 0.24s system 62% cpu 0.860 total
```
These times are now fast enough to avoid any further special-casing for
`--preinstall`, roll it out to users by default and not print a message
unless we've actually found some updates.
This is less than ideal but it gets the time on my machine down from ~6s
to ~2s when checking no taps. It still shows that we're doing way more
in `update.sh` than we need to be doing but that's a future PR.
Move some stuff formerly in `Library/ENV` around:
- Move `Library/ENV/$XCODE_VERSION` to `Library/Homebrew/env/super` as they are
all superenv wrappers and all symlinks to the same version. We never needed
the "separate shims for separate versions" functionality and it just adds
confusion.
- Move `Library/ENV/pkgconfig` to `Library/Homebrew/env/pkgconfig` to get more
things under `Library/Homebrew`
- Move `Library/ENV/scm` to `Library/scm` as these wrappers are not actually
used by or related to superenv (or stdenv) in any way.
We might as well be consistent about it, since it's not obvious to people
what the next step is after we've pointed out the directory isn't writable.
Fixes#476.
