Re: [PATCH] persistent-https: add go.mod to fix compile

"Dominyk Tiller via GitGitGadget" [off-list ref] writes:

From: Dominyk Tiller <redacted>

GOPATH-based builds and non module-aware builds are being deprecated
by golang upstream, which currently causes this to fail. This adds a
barebones mod file to fix the build.

The `persistent-https` code hasn't been touched for a long time but
I assume this is preferable to simply removing it from the codebase.

Before this change:

case $(go version) in \
	"go version go"1.[0-5].*) EQ=" " ;; *) EQ="=" ;; esac && \
	go build -o git-remote-persistent-https \
		-ldflags "-X main._BUILD_EMBED_LABEL${EQ}"
go: cannot find main module, but found .git/config in ../git
	to create a module there, run:
	cd ../.. && go mod init
make: *** [git-remote-persistent-https] Error 1

With which version of go?  Any recent version would fail the same
way, or only 1.16 and later?

Ref: https://blog.golang.org/go116-module-changes.

Can I ask what is affected by this 1.16 version number?  Do the
users have to use 1.16 and nothing older or newer?

As a non Go user, I am trying to see if this change is "make it work
for all users of reasonably new versions of Go" (if that is the
case, what is the "reasonably new") or "make it work for those with
1.16, and everybody else should either install 1.16 or figure out 
their own solutions".

Thanks.

Junio C Hamano wrote on 30/03/2021 20:09:

"Dominyk Tiller via GitGitGadget" [off-list ref] writes:

quoted

From: Dominyk Tiller <redacted>

GOPATH-based builds and non module-aware builds are being deprecated
by golang upstream, which currently causes this to fail. This adds a
barebones mod file to fix the build.

The `persistent-https` code hasn't been touched for a long time but
I assume this is preferable to simply removing it from the codebase.

Before this change:

case $(go version) in \
	"go version go"1.[0-5].*) EQ=" " ;; *) EQ="=" ;; esac && \
	go build -o git-remote-persistent-https \
		-ldflags "-X main._BUILD_EMBED_LABEL${EQ}"
go: cannot find main module, but found .git/config in ../git
	to create a module there, run:
	cd ../.. && go mod init
make: *** [git-remote-persistent-https] Error 1

With which version of go?  Any recent version would fail the same
way, or only 1.16 and later?

The link I referenced in the notes explains a little more in depth, but
there's an environment variable you can use with 1.16 to temporarily
mitigate the failure, i.e. `export GO111MODULE=off`, but regardless of
the presence of that the lack of module-awareness will become a hard
failure in Go 1.17. The lack of module awareness is only a failure on Go
1.16 and later. Module support was added in basic form as far back as Go
1.11, released late 2018.

quoted

Ref: https://blog.golang.org/go116-module-changes.

diff --git a/contrib/persistent-https/go.mod b/contrib/persistent-https/go.mod
new file mode 100644
index 000000000000..6028b1fe5e62
--- /dev/null
+++ b/contrib/persistent-https/go.mod

@@ -0,0 +1,3 @@
+module github.com/git/git/contrib/persistent-https
+
+go 1.16

Can I ask what is affected by this 1.16 version number?  Do the
users have to use 1.16 and nothing older or newer?

As a non Go user, I am trying to see if this change is "make it work
for all users of reasonably new versions of Go" (if that is the
case, what is the "reasonably new") or "make it work for those with
1.16, and everybody else should either install 1.16 or figure out 
their own solutions".

Thanks.

This is more thoroughly detailed here:
https://golang.org/ref/mod#go-mod-file-go, but essentially the version
number was/is intended to be the minimum Go version the module is
designed to work with. We could set it lower to play it safe if the Git
project wishes, but to date there have been no backwards
incompatibilities with the module system and the way we're using the
module system is so basic I don't see any way we'd trigger the
version-based behaviours detailed in the link above. For what it's worth
testing locally against 1.15 it builds without issue, despite being a
lower version number than specified in the string.

Dom
===