The documentation explains this:

The first step is to resolve which dependencies to add.

For each named package or package pattern, get must decide which version of
the corresponding module to use. By default, get chooses the latest tagged
release version, such as v0.4.5 or v1.2.3. If there are no tagged release
versions, get chooses the latest tagged prerelease version, such as
v0.0.1-pre1. If there are no tagged versions at all, get chooses the latest
known commit.

This default version selection can be overridden by adding an @version
suffix to the package argument, as in 'go get golang.org/x/text@v0.3.0'.
For modules stored in source control repositories, the version suffix can
also be a commit hash, branch identifier, or other syntax known to the
source control system, as in 'go get golang.org/x/text@master'.
The version suffix @latest explicitly requests the default behavior
described above.

If a module under consideration is already a dependency of the current
development module, then get will update the required version.
Specifying a version earlier than the current required version is valid and
downgrades the dependency. The version suffix @none indicates that the
dependency should be removed entirely.

Although get defaults to using the latest version of the module containing
a named package, it does not use the latest version of that module's
dependencies. Instead it prefers to use the specific dependency versions
requested by that module. For example, if the latest A requires module
B v1.2.3, while B v1.2.4 and v1.3.1 are also available, then 'go get A'
will use the latest A but then use B v1.2.3, as requested by A. (If there
are competing requirements for a particular module, then 'go get' resolves
those requirements by taking the maximum requested version.)

The -u flag instructs get to update dependencies to use newer minor or
patch releases when available. Continuing the previous example,
'go get -u A' will use the latest A with B v1.3.1 (not B v1.2.3).

The -u=patch flag (not -u patch) instructs get to update dependencies
to use newer patch releases when available. Continuing the previous example,
'go get -u=patch A' will use the latest A with B v1.2.4 (not B v1.2.3).

By saying github.com/pkg/errors on the command line you are implicitly saying github.com/pkg/errors@latest. The -u=patch applies to dependencies of the listed packages/modules, not to those packages/modules themselves.

Maybe we can revisit semantics for Go 1.12 but these are the Go 1.11 semantics.

I would agree with the original poster, that this behaviour is very confusing, even reading the docs several times its wasn't clear and caused much hair pulling and time wasted.

I believe the reason for this is that it states dependencies and if you running go -u get <package> in your repo <package> is a dependency.

The use case IMO for running go get -u=patch <package> is to update just <package> and its dependencies using the patch strategy.

With the current design there is no easy way to update a specific package and its dependencies using the patch strategy. The only option is to manually visit to the repo site look for the version and issue the manual go get -u=patch <package>@vX.Y.Z which is a royal PITA.

go get -u=patch some/binary@latest has a pretty clear use-case: you want to build and install the latest version of some/binary@latest, using the patch releases of its dependencies. After #24250 is addressed, that may well be the best default for installing tools from outside of a module. On the other hand, outside of a module, some/binary and some/binary@latest resolve to the same version anyway: perhaps we should only implicitly add @latest to new dependencies rather than existing ones, uniformly.

There is also a bit of a skew between the old and new go get behaviors without -u: in GOPATH mode, go get foo for some package foo already in GOPATH/src does not upgrade the version, but in module mode it implicitly upgrades to @latest.

That provides an opportunity for a nice symmetry: if the @latest version is necessary to upgrade the named package to the latest version, then we could add a similar version @patch, with the meaning “the latest patch release of the minor version already in the module graph”.

I don't think we'll get to this for 1.12, but I'd like to at least make a decision on it early in 1.13

Per (brief) discussion above and more in person, I think we should change this. If we introduce go get x@patch, then that can mean "the latest patch version of a module x already in use" (an error if x is not already a depended-upon module). Then we can define that -u=patch changes the default version suffix from @latest to @patch.

[@patch] can mean "the latest patch version of a module x already in use" (an error if x is not already a depended-upon module). Then we can define that -u=patch changes the default version suffix from @latest to @patch.

If @patch is an error if the module is not already in use, then go get -m -u=patch some/new/module would be an error. I would argue that the user's clear intent in that case is to “install some/new/module and patch all of its dependencies”.

That suggests that @patch should decay to @latest if an explicitly-requested module is not already present in the build graph.

Change https://golang.org/cl/167747 mentions this issue: cmd/go/internal/modget: support the suffix '@patch' in 'go get'