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

$ go version
go version go1.16.5 windows/amd64

What version of Git are you using (git version)?

$ git version
git version 2.31.1.windows.1

What version of GitLab are you using (Help)?

Private Instance of:

GitLab Enterprise Edition 12.9.2-ee

Does this issue reproduce with the latest release?

Yes. Also, in version 1.16.3.

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

$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\me\AppData\Local\go-build
set GOENV=C:\Users\me\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\me\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\me\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.16.5
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\dev\electronGUI\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\me\AppData\Local\Temp\go-build3510898554=/tmp/go-build -gno-record-gcc-switches

What did you do (with results)?

There is an application that was developed and built on a Linux server. We wanted to build natively on Windows.

C:\dev> git clone https://gitlab.mydomain.com/group/subgroup/repo.git
...
C:\dev> cd repo

C:\dev\repo> go build
go: gitlab.mydomain.com/group/subgroup/dependency@v1.0.4: reading gitlab.mydomain.com/group/subgroup/dependency/dependency/go.mod at revision dependency/v1.0.4: unknown revision dependency/v1.0.4

C:\dev\repo> go mod tidy
go: gitlab.mydomain.com/group/subgroup/dependency@v1.0.4: reading gitlab.mydomain.com/group/subgroup/dependency/dependency/go.mod at revision dependency/v1.0.4: unknown revision dependency/v1.0.4

What did you expect to see?

When I perform the same actions on Linux (and I delete the go/pkg directory first), I would expect to see:
go: downloading gitlab.mydomain.com/group/subgroup/dependency v1.0.4
...

Further research...

I deleted the go.mod and go.sum files. I performed a go mod init and then a go mod tidy.

C:\dev\repo> go mod tidy
go: finding module for package gitlab.mydomain.com/group/subgroup/dependency/package
repo imports
        gitlab.mydomain.com/group/subgroup/dependency/package: module gitlab.mydomain.com/group/subgroup/dependency/package: git ls-remote -q origin in C:\Users\me\go\pkg\mod\cache\vcs\54e9acdb53cfeb2d47fd466e4c76c70590c3584874e86efb8a97d80c53287648: exit status 128:
        remote: The project you were looking for could not be found.
        fatal: repository 'https://gitlab.mydomain.com/group/subgroup.git/' not found

It appears as if Go is requesting the subgroup as a repository?! That is not correct. I am sure there is an underlying reason for this behavior, but it leaves users unclear about root cause.

I performed a git clone https://gitlab.mydomain.com/group/subgroup/dependency.git successfully. So, a direct git clone command was successful. As I had setup a credential helper, this was even non-interactive. It left me unsure about root cause, appearing that access was not an issue.

I did some online research and found #34094. This seemed relevant but did not provide immediate clarity for resolving the issue. There was some mention about non-support for interactive logins. There was also mention about private repositories, which is how dependency.git was setup.

Finally, I found #24606 go get on Windows. By setting up the _netrc in my User directory, I was able to resolve the issue.

If I am understanding the Go behaviour properly, it appears as if Go is accessing GitLab directly without Git (as git is setup with a credential helper) and having an access issue. However, it is not displaying any message indicating an access issue. It would be nice to have a message that displays some sort of access failure instead of this fallback that attempts to git a non-existent repository.