cmd/go: add ability to allow mod tidy to ignore certain subdirectories

[chewxy]

What version of Go are you using (go version)?

$ go version
go version go 1.17.1 linux/amd64

Does this issue reproduce with the latest release?

Yes? Will try later

What operating system and processor architecture are you using (go env)?

go env Output

$ go env

What did you do?

Context
I'm using git. I'm working on a long running new-version branch. I receive a request to patch something on main branch. So I quickly create a new branch from main. Think of it as something like this:

    │
    │\
    │ \
    │  \
    │   │
    │   │
main│   │
    │   │
    │   │newver
    │   │
    │   │
    │   │
    │   │
    │   │
    │   │
    ▼   ▼
     \
      \
       \
        │
        │patch
        │
        │
        ▼

Now in the newver branch there are a number of new subdirectories/subpackages etc. Because it's quite experimental, not all of the subdirectories will be staged and committed into the branch. Thus when I switch to the new branch, there are some subdirectories that are not removed (let's use for example a subpackage called machine). Some are removed because they're already staged and committed to newver (and let's use for example, a package called statistics) .

What I did
So, now I'm in the patch branch, with some new subdirectories. I add a 2 line patch. Then I run go mod tidy.

go mod tidy recursively goes into each subdirectory and does its module thing. Fantastic. The issue is the code in machine refers to the subpackage statistics. Ah, now we run into a problem - it's going to be 404 not found (unrecognized import path).

What I did to overcome the issue

There were two options I had:

1. stash the changes in patch branch, go back to newver, make a new branch off newver, call it newverexp and add all the experimental stuff that is not ready for newver, then go back to the patch branch, unstash the changes, run go mod tidy and push changes. Outcome: I now have more branches to manage!
2. backup those subdirectories and delete them, run go mod tidy and then restore them from backup.

Either way, both options took more time than expected. Now, you might say "this is just your poor git hygiene". And I'd be inclined to agree with you.

What would be nicer

It would make things a lot more expedient if I could just tell go mod tidy to not recursively go into certain directories that has .go files in them because:

1. they may actually be data files with the same extension
2. they may be temporary

[mvdan]

Going the route of #30058, have you thought of dropping a temporary go.mod file in that subdirectory? Then any commands like go mod tidy or go build ./... would entirely skip it. It doesn't matter what the go.mod file contains, it could be entirely empty - the point is that with such a file being present, then that directory sub-tree is entirely ignored for the parent module, as it's assumed to be a nested module.

[bcmills]

I think there are already enough options for this sort of use case.

• Personally, I tend to use git stash in this sort of situation.
• A temporary go.mod file to prune out the new code, as Daniel suggests, would also work.
• Or you could temporarily rename the machine directory to _machine or similar. (The go command ignores directories that begin with _ or . or are named testdata.)
• Or, use go mod tidy -e to suppress the error for the missing statistics package. (That may still add dependencies for other packages imported by machine, though.)
• Or, as you noted, commit the changes on a branch somewhere, and remember where you left them. (I often have work-in-progress commits in my working branch on top of the work that I've already mailed out for review — the Go project's git codereview tool even recognizes sentences like DO NOT MAIL and DO NOT MERGE in commit messages for exactly that sort of situation.)

Honestly, I think that list of options is already too long — it's hard to know which to use when! I don't want to add to it further. 😅

[mpx]

It might be useful to document these options somewhere easily found when using mod tidy. I suspect many people will find options beyond git stash non-obvious (eg, skipping _ is not that well known, same with using go.mod to suppress dependencies).

FWIW, I regularly do the git stash; go mod tidy; git stash pop dance, along with moving/renaming files. I'd be interested to improve this workflow, but I'm not sure what that would look like. For Git, it would be convenient if go mod tidy had an option to only consider files in the index -- but this level of integration probably isn't appropriate.

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)