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.

As requested in https://github.com/Homebrew/homebrew-core/issues/9316.

Fixes #1600.

Older versions of Git don't have this flag and we don't want to block
updates for them when there's a (relatively) simple workaround.

Will only happen once but could be confusing anyway.

Only run for Homebrew developers so assume they don’t want to switch
back to an old stable branch.

Fixes #1141.

This makes the code easier to follow rather than having to know
HOMEBREW_NO_UPDATE_CLEANUP implies not updating to a tag.

Otherwise if we've committed to `master` and someone `brew update`s
before we cut the tag then they won't be updated to the latest version.

This avoids creating a new branch that’ll never be deleted for each tag
and differentiates between the `master` and `stable` branches.

Restoring stable branch post-update could lead to unsuspecting users
with homebrew.devcmdrun being stuck forever on an old tag.

Fixes #1111.

Otherwise random e.g. `pr-123` tags may cause `brew update` to update
to the wrong version.

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.

To test the tag update functionality allow setting
`HOMEBREW_UPDATE_TO_TAG`.

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.

We use these for updating people who just follow 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.

Rather than repeating origin multiple times.

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.

We’re defining developers as people who have run a dev-cmd at least
once.

Closes #877

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.

This reverts commit b6afa228 from #778.

Otherwise it can end up as e.g. `bin/git` which then breaks when we
`cd` to another directory and try to run it.

- Inconsistent or unneeded indentation
- Missing or superfluous empty lines
- Missing or wrongly formatted arguments in command summary
- Missing punctuation

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 985c672b.

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.

Otherwise this can prevent taps from being updated as expected.

This can just live in `brew.sh` and then it doesn’t need repeated in
all the other places.

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.

Fixes #671.

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.

Closes #588.

Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>