-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/go: go build
fails to read vcs info from isolated git submodule
#53640
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
go build
fails to read vcs info from isolated git submodule
I mean, if you phrase the title like this... It cannot read it from there because the submodule that is checked out has, instead of .git folder, a .git file. This file only has the content like:
So, clearly it cannot read it. So the better question is: Why is it needed that VCS is read? And if it's needed, then I am probably the wrongdoer myself for having the isolated submodule? |
I would consider this a git issue (the way it handles git dirs in submodules). |
I would refer you to the description of the build flag https://pkg.go.dev/cmd/go#:~:text=buildmode%27%20for%20more.-,%2Dbuildvcs,-Whether%20to%20stamp |
If this is the standard layout for a Git submodule, then perhaps we should change |
we can ignore(goto omitVCS when cfg.BuildBuildvcs is auto) vcsCmd.Status err when .git is file(submodule) go/src/cmd/go/internal/load/pkg.go Lines 2479 to 2486 in 9a2001a
|
Change https://go.dev/cl/443597 mentions this issue: |
Currently, FromDir identifies a VCS checkout directory just by checking whether it contains a specified file. This is not enough. For example, although there is a ".git" file (a plain file, not a directory) in a git submodule directory, this directory is not a git repository root. This change takes the file mode into account. As of now, the filename and file mode for the supported VCS tools are: - Mercurial: .hg directory - Git: .git directory - Bazaar: .bzr directory - Subversion: .svn directory - Fossil: .fslckout plain file - Fossil: _FOSSIL_ plain file This CL effectively reverts CL 30948 for golang#10322. Fixes golang#53640. Change-Id: Iea316c7e983232903bddb7e7f6dbaa55e8498685 GitHub-Last-Rev: 7a2d6ff GitHub-Pull-Request: golang#56296 Reviewed-on: https://go-review.googlesource.com/c/go/+/443597 Auto-Submit: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
This in order to fix the following bug: golang/go#53640
This in order to fix the following bug: golang/go#53640
What version of Go are you using (
go version
)?1.18.3
Does this issue reproduce with the latest release?
Yes, with latest 1.18 (that is, 1.18.3), which is not the latest Go release itself, though
What operating system and processor architecture are you using (
go env
)?It's a docker container but reproduces on Apple Silicon and on Debian 10 x86.
What did you do?
I just tried building my image:
and got output:
What did you expect to see?
No error.
What did you see instead?
Failure.
So, to make this reproducible, I created a nested git repository because the error does not occur if I remove the nested/.git file. Recursively cloning the repo,
cd
ing into nested and then run aforementioned build command reproduces it for me on two systems:https://github.com/MichaelVoelkel/vcs-test
I mean, sure,
.git
links to a folder that does not exist and just not copying everything into Docker would immediately help. But why does Go even care?The text was updated successfully, but these errors were encountered: