Go update all modules

Using this module as an example (using a specific commit so others will see
what I see):

git clone git://github.com/walles/moar
Set-Location moar
git checkout d24acdbf

I would like a way to tell Go to "update everything". Assume that the module
will work with the newest version of everything. Below are five ways I found to
do this, assume each is run on a clean clone. This results in a go.mod of 19
lines:

go get -u

This results in a go.mod of 14 lines:

go get -u
go mod tidy

This results in a go.mod of 13 lines:

go mod tidy

If I just manually delete everything in require and run go mod tidy, I get
12 lines. If I just manually delete everything in require and run go get -u, I get 11 lines. My question is, why are these methods producing different
results, and what is the "right way" to do what I am trying to do?

tl;dr;

this is what you want:

go get -u
go mod tidy

and to recursively update packages in any subdirectories:

go get -u ./...

The inconsistencies you are seeing is due to the inherent organic nature of software.

Using your example, commit d24acdbf of git://github.com/walles/moar most likely was checked in by the maintainer without running go mod tidy (explaining the longer 19 lines). If the maintainer had, then you would see the 13 line version you see at the end.

go get -u on it's own is more aggressive in pulling in dependencies. Also, the mere fact of updating dependencies to their latest (compatible) version, may in & of itself pull in new direct/indirect dependencies. These dependencies may grow even further if you tried this tomorrow (the latest version of some sub-dependency adds new functionality, so it needs new dependencies). So there may be a valid reason the repo maintainer fixes at a particular (non-latest) version.

go mod tidy cleans up this aggressive dependency analysis.

P.S. It's a common misconception that dependencies will shrink after go mod tidy: tracking go.sum, in some cases this file will grow after a tidy (though, not in this case)

Stack Overflow Q#67201708, score: 371