// fix update packages to use new APIs
// fmt gofmt (reformat) package sources
// generate generate Go files by processing source
-// get add dependencies to current module and install them
+// get download and install packages and dependencies
// install compile and install packages and dependencies
// list list packages or modules
// mod module maintenance
// For more about specifying packages, see 'go help packages'.
//
//
-// Add dependencies to current module and install them
+// Download and install packages and dependencies
//
// Usage:
//
-// go get [-d] [-m] [-u] [-v] [-insecure] [build flags] [packages]
+// go get [-d] [-f] [-t] [-u] [-v] [-fix] [-insecure] [build flags] [packages]
//
-// Get resolves and adds dependencies to the current development module
-// and then builds and installs them.
-//
-// 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, downgrading or removing modules
-// depending on it as needed.
-//
-// 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).
+// Get downloads the packages named by the import paths, along with their
+// dependencies. It then installs the named packages, like 'go install'.
//
-// 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).
+// The -d flag instructs get to stop after downloading the packages; that is,
+// it instructs get not to install the packages.
//
-// In general, adding a new dependency may require upgrading
-// existing dependencies to keep a working build, and 'go get' does
-// this automatically. Similarly, downgrading one dependency may
-// require downgrading other dependencies, and 'go get' does
-// this automatically as well.
+// The -f flag, valid only when -u is set, forces get -u not to verify that
+// each package has been checked out from the source control repository
+// implied by its import path. This can be useful if the source is a local fork
+// of the original.
//
-// The -m flag instructs get to stop here, after resolving, upgrading,
-// and downgrading modules and updating go.mod. When using -m,
-// each specified package path must be a module path as well,
-// not the import path of a package below the module root.
+// The -fix flag instructs get to run the fix tool on the downloaded packages
+// before resolving dependencies or building the code.
//
// The -insecure flag permits fetching from repositories and resolving
// custom domains using insecure schemes such as HTTP. Use with caution.
//
-// The second step is to download (if needed), build, and install
-// the named packages.
+// The -t flag instructs get to also download the packages required to build
+// the tests for the specified packages.
//
-// If an argument names a module but not a package (because there is no
-// Go source code in the module's root directory), then the install step
-// is skipped for that argument, instead of causing a build failure.
-// For example 'go get golang.org/x/perf' succeeds even though there
-// is no code corresponding to that import path.
+// The -u flag instructs get to use the network to update the named packages
+// and their dependencies. By default, get uses the network to check out
+// missing packages but does not use it to look for updates to existing packages.
//
-// Note that package patterns are allowed and are expanded after resolving
-// the module versions. For example, 'go get golang.org/x/perf/cmd/...'
-// adds the latest golang.org/x/perf and then installs the commands in that
-// latest version.
+// The -v flag enables verbose progress and debug output.
//
-// The -d flag instructs get to download the source code needed to build
-// the named packages, including downloading necessary dependencies,
-// but not to build and install them.
+// Get also accepts build flags to control the installation. See 'go help build'.
//
-// With no package arguments, 'go get' applies to the main module,
-// and to the Go package in the current directory, if any. In particular,
-// 'go get -u' and 'go get -u=patch' update all the dependencies of the
-// main module. With no package arguments and also without -u,
-// 'go get' is not much more than 'go install', and 'go get -d' not much
-// more than 'go list'.
+// When checking out a new package, get creates the target directory
+// GOPATH/src/<import-path>. If the GOPATH contains multiple entries,
+// get uses the first one. For more details see: 'go help gopath'.
//
-// For more about modules, see 'go help modules'.
+// When checking out or updating a package, get looks for a branch or tag
+// that matches the locally installed version of Go. The most important
+// rule is that if the local installation is running version "go1", get
+// searches for a branch or tag named "go1". If no such version exists
+// it retrieves the default branch of the package.
+//
+// When go get checks out or updates a Git repository,
+// it also updates any git submodules referenced by the repository.
+//
+// Get never checks out or updates code stored in vendor directories.
//
// For more about specifying packages, see 'go help packages'.
//
-// This text describes the behavior of get using modules to manage source
-// code and dependencies. If instead the go command is running in GOPATH
-// mode, the details of get's flags and effects change, as does 'go help get'.
-// See 'go help modules' and 'go help gopath-get'.
+// For more about how 'go get' finds source code to
+// download, see 'go help importpath'.
//
-// See also: go build, go install, go clean, go mod.
+// This text describes the behavior of get when using GOPATH
+// to manage source code and dependencies.
+// If instead the go command is running in module-aware mode,
+// the details of get's flags and effects change, as does 'go help get'.
+// See 'go help modules' and 'go help module-get'.
+//
+// See also: go build, go install, go clean.
//
//
// Compile and install packages and dependencies
// See https://golang.org/s/go15vendor for details.
//
//
-// Legacy GOPATH go get
-//
-// The 'go get' command changes behavior depending on whether the
-// go command is running in module-aware mode or legacy GOPATH mode.
-// This help text, accessible as 'go help gopath-get' even in module-aware mode,
-// describes 'go get' as it operates in legacy GOPATH mode.
-//
-// Usage: go get [-d] [-f] [-t] [-u] [-v] [-fix] [-insecure] [build flags] [packages]
-//
-// Get downloads the packages named by the import paths, along with their
-// dependencies. It then installs the named packages, like 'go install'.
-//
-// The -d flag instructs get to stop after downloading the packages; that is,
-// it instructs get not to install the packages.
-//
-// The -f flag, valid only when -u is set, forces get -u not to verify that
-// each package has been checked out from the source control repository
-// implied by its import path. This can be useful if the source is a local fork
-// of the original.
-//
-// The -fix flag instructs get to run the fix tool on the downloaded packages
-// before resolving dependencies or building the code.
-//
-// The -insecure flag permits fetching from repositories and resolving
-// custom domains using insecure schemes such as HTTP. Use with caution.
-//
-// The -t flag instructs get to also download the packages required to build
-// the tests for the specified packages.
-//
-// The -u flag instructs get to use the network to update the named packages
-// and their dependencies. By default, get uses the network to check out
-// missing packages but does not use it to look for updates to existing packages.
-//
-// The -v flag enables verbose progress and debug output.
-//
-// Get also accepts build flags to control the installation. See 'go help build'.
-//
-// When checking out a new package, get creates the target directory
-// GOPATH/src/<import-path>. If the GOPATH contains multiple entries,
-// get uses the first one. For more details see: 'go help gopath'.
-//
-// When checking out or updating a package, get looks for a branch or tag
-// that matches the locally installed version of Go. The most important
-// rule is that if the local installation is running version "go1", get
-// searches for a branch or tag named "go1". If no such version exists
-// it retrieves the default branch of the package.
-//
-// When go get checks out or updates a Git repository,
-// it also updates any git submodules referenced by the repository.
-//
-// Get never checks out or updates code stored in vendor directories.
-//
-// For more about specifying packages, see 'go help packages'.
-//
-// For more about how 'go get' finds source code to
-// download, see 'go help importpath'.
-//
-// This text describes the behavior of get when using GOPATH
-// to manage source code and dependencies.
-// If instead the go command is running in module-aware mode,
-// the details of get's flags and effects change, as does 'go help get'.
-// See 'go help modules' and 'go help module-get'.
-//
-// See also: go build, go install, go clean.
-//
-//
// Module proxy protocol
//
// The go command by default downloads modules from version control systems
// Modules replace the old GOPATH-based approach to specifying
// which source files are used in a given build.
//
-// Module support
+// Preliminary module support
//
-// Go 1.13 includes official support for Go modules,
-// including a module-aware 'go get' command.
-// Module-aware mode is active by default.
+// Go 1.11 includes preliminary support for Go modules,
+// including a new module-aware 'go get' command.
+// We intend to keep revising this support, while preserving compatibility,
+// until it can be declared official (no longer preliminary),
+// and then at a later point we may remove support for work
+// in GOPATH and the old 'go get' command.
//
-// For more fine-grained control, Go 1.13 continues to respect
+// The quickest way to take advantage of the new Go 1.11 module support
+// is to check out your repository into a directory outside GOPATH/src,
+// create a go.mod file (described in the next section) there, and run
+// go commands from within that file tree.
+//
+// For more fine-grained control, the module support in Go 1.11 respects
// a temporary environment variable, GO111MODULE, which can be set to one
-// of three string values: off, auto, or on (the default).
-// If GO111MODULE=on or is unset, then the go command requires the use of
-// modules, never consulting GOPATH. We refer to this as the command
-// being module-aware or running in "module-aware mode".
-// If GO111MODULE=auto, then the go command enables or disables module
-// support based on the current directory. Module support is enabled only
-// when the current directory is outside GOPATH/src and itself contains a
-// go.mod file or is below a directory containing a go.mod file.
-// If GO111MODULE=off, then the go command never uses
-// module support. Instead it looks in vendor directories and GOPATH
+// of three string values: off, on, or auto (the default).
+// If GO111MODULE=off, then the go command never uses the
+// new module support. Instead it looks in vendor directories and GOPATH
// to find dependencies; we now refer to this as "GOPATH mode."
+// If GO111MODULE=on, then the go command requires the use of modules,
+// never consulting GOPATH. We refer to this as the command being
+// module-aware or running in "module-aware mode".
+// If GO111MODULE=auto or is unset, then the go command enables or
+// disables module support based on the current directory.
+// Module support is enabled only when the current directory is outside
+// GOPATH/src and itself contains a go.mod file or is below a directory
+// containing a go.mod file.
//
// In module-aware mode, GOPATH no longer defines the meaning of imports
// during a build, but it still stores downloaded dependencies (in GOPATH/pkg/mod)
// are still ignored.
//
//
+// Module-aware go get
+//
+// The 'go get' command changes behavior depending on whether the
+// go command is running in module-aware mode or legacy GOPATH mode.
+// This help text, accessible as 'go help module-get' even in legacy GOPATH mode,
+// describes 'go get' as it operates in module-aware mode.
+//
+// Usage: go get [-d] [-m] [-u] [-v] [-insecure] [build flags] [packages]
+//
+// Get resolves and adds dependencies to the current development module
+// and then builds and installs them.
+//
+// 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, downgrading or removing modules
+// depending on it as needed.
+//
+// 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).
+//
+// In general, adding a new dependency may require upgrading
+// existing dependencies to keep a working build, and 'go get' does
+// this automatically. Similarly, downgrading one dependency may
+// require downgrading other dependencies, and 'go get' does
+// this automatically as well.
+//
+// The -m flag instructs get to stop here, after resolving, upgrading,
+// and downgrading modules and updating go.mod. When using -m,
+// each specified package path must be a module path as well,
+// not the import path of a package below the module root.
+//
+// The -insecure flag permits fetching from repositories and resolving
+// custom domains using insecure schemes such as HTTP. Use with caution.
+//
+// The second step is to download (if needed), build, and install
+// the named packages.
+//
+// If an argument names a module but not a package (because there is no
+// Go source code in the module's root directory), then the install step
+// is skipped for that argument, instead of causing a build failure.
+// For example 'go get golang.org/x/perf' succeeds even though there
+// is no code corresponding to that import path.
+//
+// Note that package patterns are allowed and are expanded after resolving
+// the module versions. For example, 'go get golang.org/x/perf/cmd/...'
+// adds the latest golang.org/x/perf and then installs the commands in that
+// latest version.
+//
+// The -d flag instructs get to download the source code needed to build
+// the named packages, including downloading necessary dependencies,
+// but not to build and install them.
+//
+// With no package arguments, 'go get' applies to the main module,
+// and to the Go package in the current directory, if any. In particular,
+// 'go get -u' and 'go get -u=patch' update all the dependencies of the
+// main module. With no package arguments and also without -u,
+// 'go get' is not much more than 'go install', and 'go get -d' not much
+// more than 'go list'.
+//
+// For more about modules, see 'go help modules'.
+//
+// For more about specifying packages, see 'go help packages'.
+//
+// This text describes the behavior of get using modules to manage source
+// code and dependencies. If instead the go command is running in GOPATH
+// mode, the details of get's flags and effects change, as does 'go help get'.
+// See 'go help modules' and 'go help gopath-get'.
+//
+// See also: go build, go install, go clean, go mod.
+//
+//
// Package lists and patterns
//
// Many commands apply to a set of packages: