What does `go get -u ./...` do in a Go module, and how does `-u=patch` differ?

## What the command is actually made of `go get -u ./...` has three separable parts, and most confusion about it comes from blurring them. **`go get`** is the dependency-management command. In current Go it does exactly one job: it changes which module versions your main module requires, editing `go.mod` and recording the new hashes in `go.sum`. It stopped building and installing packages in Go 1.18; installing a program from a module you do not depend on is `go install example.com/cmd@latest`, which does not touch your `go.mod` at all. If you remember `go get` as "the command that downloads and installs a tool", that memory is from a Go that no longer exists. **`./...`** is a package pattern, not a module pattern. It expands to every package in the directory tree rooted at the current directory — in practice, all the packages of your own module. You are naming *your* packages, and the upgrade is derived from what they import. **`-u`** is the upgrade flag. It says: for the packages named on the command line, upgrade the modules providing them *and the modules providing everything they import, directly or indirectly*, to newer minor or patch releases when such releases exist. That transitive reach is the part people underestimate. `go get -u ./...` is not "bump my direct dependencies"; it is "bump essentially the whole build list", and a single run can move dozens of modules across minor versions. ## `-u` versus `-u=patch` `-u=patch` performs the same traversal but restricts every module to the highest patch release within the minor version it is already on. A module at `v1.4.0` may reach `v1.4.7`; it will not reach `v1.5.0`. Semantically a patch release should contain only bug fixes, so `-u=patch` is the low-blast-radius upgrade: it is what a scheduled bump job runs when it wants the diff to be safe to merge with a light review. `-u` is the higher-yield, higher-risk upgrade: new minors bring new behaviour, new deprecations, and sometimes new transitive requirements of their own. Both flags obey the same two limits. First, they only consider **release** versions — a module with only a pre-release tag such as `v1.5.0-rc.1` is not chosen by `-u`. Second, they never change a module path, and a major version from `v2` onward *is* a different path (`example.com/lib/v2`). So `-u` cannot perform a major upgrade; that is an import-path edit you make deliberately. ## Looking before you leap The read-only companion is `go list -m -u all`. `-m` makes the command list **modules** rather than packages, `all` is the module pattern covering everything in the build list, and `-u` annotates each line with the newest available version in square brackets: ``` example.com/api v1.6.0 [v1.7.1] example.com/log v1.2.0 [v1.2.4] ``` A line with no bracket is already current. This is the survey you run before deciding whether this week's upgrade is a patch sweep or a real minor bump, and it changes nothing on disk. ## Why the upgrade has to be explicit at all Since Go 1.16 the build commands default to `-mod=readonly`: `go build` and `go test` will not silently add or upgrade a requirement to make your code compile — they fail and tell you which `go get` to run. That is a deliberate design choice. Upgrades are a version-control event, reviewable as a diff of `go.mod` and `go.sum`, rather than something that happens invisibly on a developer's machine and produces a build nobody else can reproduce. ## After the upgrade Run the tests. Then run `go mod tidy`, which adds any requirement that the new versions made necessary and drops any that became unused; note that tidy will not undo your upgrade — it does not downgrade requirements that are still needed. Review the `go.mod` diff line by line: on a modern `go` directive line, an upgrade of one direct dependency frequently rewrites several `// indirect` lines too, and those are the lines where behaviour you never asked about can change.