hop migrate reads what Homebrew has installed and offers to reinstall it under hop — without brew running, without touching your existing Homebrew install, and without removing anything unless you type the command to do it yourself.
hop migrate --dry-run to see, with no risk, exactly what hop could take over from your existing Homebrew install. If it looks right, drop --dry-run and hop installs those same tools under itself. Homebrew is left completely alone — both copies exist side by side until you decide to remove the old one, which hop tells you how to do but never does for you.
hop migrate reads Homebrew's Cellar directory and each formula's own install receipt directly off disk — it never shells out to brew, so brew doesn't need to be running, doesn't need to be working, and isn't touched by any of this. hop looks in the standard locations in order: $HOMEBREW_PREFIX if set, then /opt/homebrew, /usr/local, and /home/linuxbrew/.linuxbrew — or pass --prefix to point at a nonstandard install directly.
For each formula found, hop reads its install receipt to tell whether it was installed on request (something you actually asked brew for) versus pulled in automatically as another formula's dependency. By default, only on-request formulae are considered for migration — --all includes brew's own auto-installed dependencies too, though hop will resolve its own dependency graph for whatever it migrates regardless, so including brew's rarely changes anything except the list you're shown.
Nothing on disk changes yet — --dry-run only ever reports. Drop the flag, confirm the prompt (or pass -y to skip it), and hop installs exactly the migratable set as one ordinary transaction: downloaded, verified, and linked in parallel, the same as any other hop install.
hop sorts what it finds into four groups, and reports every one of them rather than silently dropping anything it can't handle:
hop migrate run installs.--all brings them into the migratable count too.Homebrew casks are GUI applications, and hop can install those too — see how a cask lands in the store and install. What migrate doesn't do yet is cross a Homebrew cask's name over to hop's own recipe for it automatically, so casks are reported (how many exist) but not migrated by this command. If hop already has a recipe for one of yours — hop search <name> will say — installing it directly with hop install works exactly like any other package.
After a real (non-dry-run) migration, both copies of every migrated tool exist on the machine at once — Homebrew's original and hop's new one. Which one actually runs when you type its name depends on PATH order, which hop doctor can check. hop prints the exact brew uninstall command for everything it just took over, but it will not run that command for you under any circumstance — removing software installed by another tool is a decision for you to make deliberately, not something a package manager does as a side effect of a different command.
Pass --write-hopfile to also record the migrated set into a hopfile.toml in the current directory — the same declarative file hop init and hop sync use for project reproducibility, so the tools you just brought over from Homebrew become part of what a second machine can reproduce with one command.