Update, 2026-03-10: Refined version: I propose that the go command only set vcs.modified=true if the modifications concern files used by the current build or files used by the same build in a clean repo with no modifications. The second half of that condition addresses a repo in which the only change is having removed a file. See #77897 (comment) for more details.
Proposal Details
If I run 'go build' in a repo with a random extra file that doesn't matter to the build, the runtime build info in the binary says vcs.modified=true and the main module path has a +dirty suffix. I propose that the go command only set vcs.modified=true if the modifications concern files used by the current build.
This will make the modified flag tell more precisely whether the binary is actually modified from the repo copy. If I've left a x.prof cpu profile lying around, and run 'go install', that shouldn't be a '+dirty' version. The most confusing behavior it would fix is this:
# assume completely clean repo
go build # creates ./foo binary; repo now "modified"
go install # installs to $GOBIN/foo with +dirty suffix, deletes ./foo; repo no longer "modified"
go install # installs to $GOBIN/foo again with no +dirty suffix
For a real example, note the discussion on robpike/ivy#267.
This is fairly straightforward, since cmd/go is already fetching the list of modified files from all the VCS. Right now it sets modified when len(listText) > 0. Instead it would need to parse the list and cross-check against the files actually used in the build.
I have this mostly implemented, but it is a visible change, so filing a proposal.
Update, 2026-03-10: Refined version: I propose that the go command only set vcs.modified=true if the modifications concern files used by the current build or files used by the same build in a clean repo with no modifications. The second half of that condition addresses a repo in which the only change is having removed a file. See #77897 (comment) for more details.
Proposal Details
If I run 'go build' in a repo with a random extra file that doesn't matter to the build, the runtime build info in the binary says vcs.modified=true and the main module path has a +dirty suffix. I propose that the go command only set vcs.modified=true if the modifications concern files used by the current build.
This will make the modified flag tell more precisely whether the binary is actually modified from the repo copy. If I've left a x.prof cpu profile lying around, and run 'go install', that shouldn't be a '+dirty' version. The most confusing behavior it would fix is this:
For a real example, note the discussion on robpike/ivy#267.
This is fairly straightforward, since cmd/go is already fetching the list of modified files from all the VCS. Right now it sets modified when len(listText) > 0. Instead it would need to parse the list and cross-check against the files actually used in the build.
I have this mostly implemented, but it is a visible change, so filing a proposal.