cmd/go: 'Filename too long' when cloning a repo into the module cache

[bcmills]

TestScript/mod_convert fails on Windows when starting from a clean module cache, due to a Filename too long error when cloning a Git repository.

    --- FAIL: TestScript/mod_convert (167.75s)
        script_test.go:252:
            > [short] skip
            > [!net] skip
            > [!exec:git] skip
            > env GO111MODULE=on
            > env GOPROXY=
            > env GOSUMDB=
            > go mod download github.com/docker/distribution@v0.0.0-20150410205453-85de3967aa93
            > mkdir x/Godeps
            > cp $GOPATH/pkg/mod/github.com/docker/distribution@v0.0.0-20150410205453-85de3967aa93/Godeps/Godeps.json x/Godeps
            > cd x
            $WORK\gopath\src\x
            > go mod init github.com/docker/distribution
            [stderr]
            go: creating new go.mod: module github.com/docker/distribution
…
            go: converting Godeps\Godeps.json: stat github.com/MSOpenTech/azure-sdk-for-go/storage@d90753bcad2ed782fcead7392d1e831df29aa2bb: github.com/MSOpenTech/azure-sdk-for-go/storage@d90753bcad2ed782fcead7392d1e831df29aa2bb: invalid version: git fetch -f origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in $WORK\gopath\pkg\mod\cache\vcs\554a64a2fb0fb08170d1660c0d3aa6fdd6c397908453fe3dffa37224977b38b5: exit status 1:
                From https://github.com/MSOpenTech/azure-sdk-for-go
…
                 * [new branch]          sync-eng/common-draft-pr-support-1488 -> origin/sync-eng/common-draft-pr-support-1488
72/script-mod_convert/gopath/pkg/mod/cache/vcs/554a64a2fb0fb08170d1660c0d3aa6fdd6c397908453fe3dffa37224977b38b5/./refs/remotes/origin/sync-eng/common-feature/skip_feature_branch_apireview-1483.lock': Filename too long
…
            > cmpenv go.mod go.mod.want
            [diff -go.mod +go.mod.want]
             module github.com/docker/distribution

             go 1.17

             require (
                github.com/AdRoll/goamz v0.0.0-20150130162828-d3664b76d905
            +   github.com/MSOpenTech/azure-sdk-for-go v0.0.0-20150323223030-d90753bcad2e
                github.com/Sirupsen/logrus v0.7.3
                github.com/bugsnag/bugsnag-go v1.0.3-0.20141110184014-b1d153021fcd
                github.com/bugsnag/osext v0.0.0-20130617224835-0dd3f918b21b
                github.com/codegangsta/cli v1.4.2-0.20150131031259-6086d7927ec3
                github.com/docker/docker v1.4.2-0.20150204013315-165ea5c158cf
                github.com/docker/libtrust v0.0.0-20150114040149-fa567046d9b1
                github.com/garyburd/redigo v0.0.0-20150301180006-535138d7bcd7
                github.com/gorilla/context v0.0.0-20140604161150-14f550f51af5
                github.com/gorilla/handlers v0.0.0-20140825150757-0e84b7d810c1
                github.com/gorilla/mux v0.0.0-20140926153814-e444e69cbd2e
                github.com/jlhawn/go-crypto v0.0.0-20150401213827-cd738dde20f0
                github.com/yvasiyarov/go-metrics v0.0.0-20140926110328-57bccd1ccd43
                github.com/yvasiyarov/gorelic v0.0.7-0.20141212073537-a9bba5b9ab50
                github.com/yvasiyarov/newrelic_platform_go v0.0.0-20140908184405-b21fdbd4370f
                golang.org/x/net v0.0.0-20150202051010-1dfe7915deaf
                gopkg.in/check.v1 v1.0.0-20141024133853-64131543e789
                gopkg.in/yaml.v2 v2.0.0-20150116202057-bef53efd0c76
             )

The error occurs when creating a file for a branch that is not actually needed by the test, so the test passes on subsequent runs. However, a similar error could occur for users.

This error may have been suppressed before CL 297950 (for #42751), so this might be a regression in Go 1.17.

CC @jayconrod @matloob @kevinburkemeter

[bcmills]

From https://stackoverflow.com/questions/22575662/filename-too-long-in-git-for-windows, I think this is arguably a bug in git, and it seems to have a workaround that can be applied by improving the system's Git configuration:

git config --system core.longpaths true

Closing as not a Go issue, but perhaps a usability wrinkle that we should document. (If we get many user reports about this, we can consider applying a local workaround within the Git repos in the module cache.)

[bcmills]

We ended up explicitly setting core.longpaths in https://go.dev/cl/482819 (Go 1.21).