The addition of -buildvcs reduces the amount of boilerplate needed to track VCS metadata in binaries, but also adds a certain amount of overhead when building in limited environments (notably, within Docker containers). In particular, one must load .git (or other VCS directory/config) into the build context, and one must install their VCS tool of choice within the docker build environment.

I'd like to propose as a lighter-weight alternative we introduce -buildvcs option to directly provide the metadata key(s). This could take a few different forms. Three come to mind as potentially realistic:

1. Environment variables

   -buildvcs=env means that the environment variables GO_VCS, GO_VCS_REVISION, GO_VCS_TIME and GO_VCS_MODIFIED will be used to populate vcs, vcs.revision, vcs.time, and vcs.modified, respectively.

2. External file

   -buildvcs=metadata.json means that the file metadata.json* will be consulted, and expected to contain data in the form {"vcs":"git","revision":"860db4b0de1e5551871da59301d3cf5b41131cd6","time":"Wed Nov 1 09:14:15 2023 +0100","modified":false}

   *Format, and whether an arbitrary filename is allowed, are open for debate. maybe for e.g. -buildvcs=json is better, with a fixed filename.

3. CSV on the command line

   -buildvcs="git,860db4b0de1e5551871da59301d3cf5b41131cd6,Wed Nov 1 09:14:15 2023 +0100,false" provides the metadata fields directly. Any omitted fields are ignored.

My personal preference is probably option 1, environment variables. It's probably the most directly compatible with Docker build environments (where I most care about this), and is also probably the least ambiguous and error-prone of the three.

Both option 1 and the fixed filename variant of option 2 have the potential to be triggered by -buildvcs=auto or -buildvcs=true as well, if the existing criteria for metadata detection are not met.