| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Make `brew upgrade` and `brew outdated` follow alias changes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
References #1023.
|
|
update-report: migrate everyone to new repository.
|
|
Use new "macOS" naming where appropriate.
|
|
This will hang around otherwise due to e.g. running `bundle install` in
here once.
|
|
Before stashing also try to cancel any current merge, rebase and
reset. This will prevent any data loss but also make the stash more
likely to succeed.
|
|
update-report: also create Cellar on migration.
|
|
|
|
|
|
|
|
|
|
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.
|
|
Just on the off chance it doesn't exist (i.e. no-one has installed
anything yet or you're a `test-bot` that's run `git clean -xdf`
recently)
|
|
This shouldn't be possible to occur after #1013 but it makes sense to
add it anyway.
|
|
Otherwise if they are created and empty they may be removed again
before we try to create the `/usr/local/bin/brew` symlink.
|
|
Also migrate people without `HOMEBREW_DEVELOPER` set to the new
location.
|
|
update-report: migrate /usr/local repository.
|
|
update.sh: turn origin/branch into a variable.
|
|
Migrate a HOMEBREW_REPOSITORY and HOMEBREW_PREFIX of `/usr/local` so
that the HOMEBREW_REPOSITORY is now in `/usr/local/Homebrew`. This gives
us more flexibility on changing the repository layout in future and
avoids putting junk in `/usr/local` when not necessary (e.g. our
`README.md`).
|
|
Rather than repeating origin multiple times.
|
|
|
|
Move the `LinkedKegs` migration into `utils.rb` so it can also be called
from `brew.rb` on startup.
|
|
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.
|
|
These don't make sense to be tied to the `HOMEBREW_REPOSITORY` but
instead should live in the `HOMEBREW_PREFIX` as they all relate to its
state.
|
|
These definitions are scattered throughout the codebase which makes it
hard to refactor them later (my goal is to move them outside of
HOMEBREW_LIBRARY). Unify their definitions for clearer code and easier
movement later.
|
|
cmd/commands: always show developer commands
|
|
|
|
|
|
|
