Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: "v1.x.y is not a tag" when .gitconfig sets log.decorate to full #51312

Open
hidu opened this issue Feb 22, 2022 · 32 comments
Open

cmd/go: "v1.x.y is not a tag" when .gitconfig sets log.decorate to full #51312

hidu opened this issue Feb 22, 2022 · 32 comments
Assignees
Labels
GoCommand modules NeedsFix
Milestone

Comments

@hidu
Copy link

@hidu hidu commented Feb 22, 2022

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

$ go version
go version go1.16.14 darwin/amd64

Does this issue reproduce with the latest release?

yes

Not Reproduced:
go1.14.15, go1.15.15, go1.18beta2
go1.16.13, go1.17.6

Reproduced:
go1.16.14, go1.17.7, go1.18rc1

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

go env Output
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN="/Users/work/go/bin"
GOCACHE="/Users/work/Library/Caches/go-build"
GOENV="/Users/work/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/work/go/pkg/mod"
GONOPROXY="*mydomain.com*"
GONOSUMDB="*"
GOOS="darwin"
GOPATH="/Users/work/go"
GOPRIVATE=""
GOPROXY="https://goproxy.cn,direct"
GOROOT="/Users/work/sdk/go1.16.14"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/work/sdk/go1.16.14/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16.14"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/work/workspace/myapp/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/72/byjy11cs0dj_z3rjtxnj_nn00000gn/T/go-build1154361502=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

  1. repo mydomain.com/a/bnet has tag v1.23.13.
  2. repo mydomain.com/a/bnet download direct:GONOPROXY="*mydomain.com*"
  3. repo mydomain.com/myapp require mydomain.com/a/bnet@v1.23.13
  4. clean mod cache: go clean -modcache
  5. cd mydomain.com/myapp
  6. exec go version,output: go version go1.16.14 darwin/amd64
  7. exec go mod download has error:

go mod download: mydomain.com/a/bnet@v1.23.13: invalid version: resolves to version v1.23.15-0.20220221055748-c5a5cd77b294 (v1.23.13 is not a tag)

  1. with go1.16.13, exec go1.16.13 mod download ,there is no error, download success
  2. retry with go1.16.14 ,exec go1.16.14 mod download again, success

there was no useful error message, when exec go mod doanload -x

What did you expect to see?

What did you see instead?

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Feb 22, 2022

Can you check what kind of tag v1.23.13 is? Is it possible it's a branch rather than tag? If so, issue #35671 would be related, as it was backported to Go 1.16.14 (see #50686 and third bullet point in release announcement).

@seankhliao seankhliao added the WaitingForInfo label Feb 22, 2022
@hidu
Copy link
Author

@hidu hidu commented Feb 23, 2022

v1.23.13 is a tag, not branch.

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Feb 23, 2022

@hidi Thanks for that information. Is it Git being used, or is it another VCS type? In case it ends up being relevant to this issue, can you also check what type of tag it is: (if git) lightweight or annotated? (The two git tag types are described here.)

CC @bcmills.

@dmitshur dmitshur changed the title cmd/go/mod: v1.x.y is not a tag cmd/go: unexpected "v1.x.y is not a tag" after update to Go 1.16.14 Feb 23, 2022
@dmitshur dmitshur added GoCommand NeedsInvestigation labels Feb 23, 2022
@bcmills
Copy link
Member

@bcmills bcmills commented Feb 23, 2022

@hidu, could you post the git command(s) that you used to verify that v1.23.13 is present as a tag on the remote server?

For example, for the go repo I can verify that go1.18beta2 is a tag on the origin server using git ls-remote:

~/go/src$ git ls-remote origin refs/tags/go1.18beta2
41f485b9a7d8fd647c415be1d11b612063dff21c        refs/tags/go1.18beta2

@hidu
Copy link
Author

@hidu hidu commented Feb 23, 2022

git ,is Annotated Tags,i create is by:

git tag -a v1.23.13 -m ''
$ git show v1.23.13
tag v1.23.13
Tagger: xxx <xxx@yyy.com>
Date:   Mon Feb 21 14:12:35 2022 +0800


commit xyz (tag: refs/tags/v1.23.14, tag: refs/tags/v1.23.13)
$git version
git version 2.34.1

@hidu
Copy link
Author

@hidu hidu commented Feb 23, 2022

git ls-remote origin refs/tags/v1.23.13

|Please wait a moment...
|hash-value-id refs/tags/v1.23.13

@bcmills
Copy link
Member

@bcmills bcmills commented Feb 23, 2022

commit xyz (tag: refs/tags/v1.23.14, tag: refs/tags/v1.23.13)

Hmm. Do I read correctly that the same commit is tagged with both v1.23.13 and v1.23.14?

Could you post (or would you be comfortable privately sending) the output of go mod download -x mydomain.com/a/bnet@v1.23.13?

cmd/go's interaction with git is fairly subtle, so without a concrete repo that reproduces the issue I'm not sure whether we'll be able to make much progress.

@hidu
Copy link
Author

@hidu hidu commented Feb 23, 2022

v1.23.13, v1.23.14 is the same cimmit
when v1.23.13 occurred this error, i create tag v1.23.14, v1.23.14 also occurred the same error

with go get has the some error.

go1.16.14 get -x mydomain.com/a/bnet@v1.23.13

# get https://mydomain.com/?go-get=1
# get https://mydomain.com/a/bnet?go-get=1
# get https://mydomain.com/a?go-get=1
# get https://mydomain.com/?go-get=1: Get "http://mydomain.com?go-get=1": redirected from secure URL https://mydomain.com/?go-get=1 to insecure URL http://mydomain.com?go-get=1
# get https://mydomain.com/a?go-get=1: Get "http://mydomain.com?go-get=1": redirected from secure URL https://mydomain.com/a?go-get=1 to insecure URL http://mydomain.com?go-get=1
# get https://mydomain.com/a/bnet?go-get=1: 200 OK (0.190s)
mkdir -p /Users/work/tmp/go_mod_cache/cache/vcs # git3 ssh://git@mydomain.com:8080/a/net
# lock /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0.lock# get https://mydomain.com/a?go-get=1: Get "http://mydomain.com?go-get=1": redirected from secure URL https://mydomain.com/a?go-get=1 to insecure URL http://mydomain.com?go-get=1
# /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0 for git3 ssh://git@mydomain.com:8080/a/bnet
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git tag -l
0.015s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git tag -l
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' refs/tags/v1.23.13 --
0.018s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' refs/tags/v1.23.13 --
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git ls-remote -q origin
0.300s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git ls-remote -q origin
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' refs/tags/v1.23.15 --
0.014s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' refs/tags/v1.23.15 --
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git cat-file blob hashvalue3:go.mod
0.012s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git cat-file blob hashvalue3:go.mod
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' hashvalue1 --
0.010s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' hashvalue1 --
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git cat-file blob hashvalue1:go.mod
0.008s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git cat-file blob hashvalue1:go.mod
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git for-each-ref --format %(refname) refs/tags --merged hashvalue1
0.008s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git for-each-ref --format %(refname) refs/tags --merged hashvalue1
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' hashvalue2 --
0.010s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' hashvalue2 --
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git cat-file blob hashvalue1:go.mod
0.008s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashvalue0; git cat-file blob hashvalue1:go.mod
go get: mydomain.com/a/bnet@v1.23.13: invalid version: resolves to version v1.23.15-0.20220221055748-hashvalue2 (v1.23.13 is not a tag)

the lastest version is v1.23.15

@bcmills
Copy link
Member

@bcmills bcmills commented Feb 23, 2022

go1.16.14 get -x mydomain.com/a/bnet@v1.23.13

Could you run go clean -modcache and then post go1.17,7 mod download -x mydomain.com/a/bnet@v1.23.13 specifically? go get does a lot of package-to-version resolution that makes it substantially more complicated to debug, and 1.17.7 is closer to the current code than 1.16.14 is (so it's easier to narrow down the interactions with other changes).

Could you also check whether the issue reproduces with go1.18rc1?

@hidu
Copy link
Author

@hidu hidu commented Feb 23, 2022

go1.18rc1 also reproduced

@hidu
Copy link
Author

@hidu hidu commented Feb 23, 2022

go1.17.7 mod download -x mydomain.com/a/bnet@v1.23.13

# get https://mydomain.com/a/bnet?go-get=1
# get https://mydomain.com/a/bnet?go-get=1: 200 OK (0.180s)
mkdir -p /Users/work/tmp/go_mod_cache/cache/vcs # git3 ssh://git@mydomain.com:8080/a/bnet
# lock /Users/work/tmp/go_mod_cache/cache/vcs/hashval0.lockmkdir -p /Users/work/tmp/go_mod_cache/cache/vcs/hashval0 # git3 ssh://git@mydomain.com:8080/a/bnet
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git init --bare
0.016s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git init --bare
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git remote add origin -- ssh://git@mydomain.com:8080/a/bnet
0.007s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git remote add origin -- ssh://git@mydomain.com:8080/a/bnet
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git tag -l
0.008s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git tag -l
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git ls-remote -q origin
0.288s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git ls-remote -q origin
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' hashval2 --
0.009s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' hashval2 --
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git fetch -f --depth=1 origin refs/tags/v1.23.13:refs/tags/v1.23.13
0.549s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git fetch -f --depth=1 origin refs/tags/v1.23.13:refs/tags/v1.23.13
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' refs/tags/v1.23.13 --
0.008s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' refs/tags/v1.23.13 --
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' hashval1 --
0.007s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' hashval1 --
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git fetch -f --depth=1 origin refs/tags/v1.23.15:refs/tags/v1.23.15
0.244s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git fetch -f --depth=1 origin refs/tags/v1.23.15:refs/tags/v1.23.15
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' refs/tags/v1.23.15 --
0.008s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' refs/tags/v1.23.15 --
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git cat-file blob hashval1:go.mod
0.007s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git cat-file blob hashval1:go.mod
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' hashval2 --
0.007s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' hashval2 --
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git cat-file blob hashval2:go.mod
0.007s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git cat-file blob hashval2:go.mod
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git for-each-ref --format %(refname) refs/tags --merged hashval2
0.010s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git for-each-ref --format %(refname) refs/tags --merged hashval2
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' hashval2 --
0.007s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' hashval2 --
cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git cat-file blob hashval2:go.mod
0.010s # cd /Users/work/tmp/go_mod_cache/cache/vcs/hashval0; git cat-file blob hashval2:go.mod
go mod download: mydomain.com/a/bnet@v1.23.13: invalid version: resolves to version v1.23.15-0.20220221055748-hashval2 (v1.23.13 is not a tag)

@bcmills bcmills self-assigned this Feb 23, 2022
@bcmills bcmills added modules and removed WaitingForInfo labels Feb 23, 2022
@bcmills bcmills added this to the Go1.18 milestone Feb 23, 2022
@bcmills
Copy link
Member

@bcmills bcmills commented Feb 23, 2022

Ok, so from that trace I would expect that hashval1 is the latest tagged release (checking for retract directives, maybe?), and hashval2 is the actual commit to which v1.23.13 refers.

Does the repo contain a go.mod file at v1.23.13? If so, does its module line declare module mydomain.com/a/bnet?

@hidu
Copy link
Author

@hidu hidu commented Feb 23, 2022

yes , tag v1.23.15 is the latest, commit ID is hashval1, and v1.23.13's commit ID is hashval2

for the above test, go.mod file:

require mydomain.com/a/bnet v1.23.13

with go.mod file require mydomain.com/a/bnet v1.23.13, exec go1.17.7 mod download -x mydomain.com/a/bnet@v1.23.13 also has same error.

go1.17.7 mod download -x mydomain.com/a/bnet@other_exits_vesions has same error.

repo bnet's go.mod:

module mydomain.com/a/bnet

go 1.16

@hidu
Copy link
Author

@hidu hidu commented Feb 23, 2022

--- a/src/cmd/go/internal/modfetch/coderepo.go
+++ b/src/cmd/go/internal/modfetch/coderepo.go
@@ -389,7 +389,7 @@ func (r *codeRepo) convert(info *codehost.RevInfo, statVers string) (*RevInfo, e
        Path: r.modPath,
        Err: &module.InvalidVersionError{
            Version: statVers,
-           Err:     fmt.Errorf("resolves to version %v (%s is not a tag)", v, statBase),
+           Err:     fmt.Errorf("resolves to version %v (%s is not a tag)(wantbase=%s)", v, statBase,base),
          },
       }
  }
coderepo.go line-383 Code
if statVers != "" && statVers == module.CanonicalVersion(statVers) {
	// Since the caller-requested version is canonical, it would be very
	// confusing to resolve it to anything but itself, possibly with a
	// "+incompatible" suffix. Error out explicitly.
	if statBase := strings.TrimSuffix(statVers, "+incompatible"); statBase != base {
		return nil, &module.ModuleError{
			Path: r.modPath,
			Err: &module.InvalidVersionError{
				Version: statVers,
				Err:     fmt.Errorf("resolves to version %v (%s is not a tag)(wantbase=%s)", v, statBase,base),
			},
		}
	}
}
Error:

go mod download -x mydomain.com/a/bnet@v1.23.2 :

go mod download: mydomain.com/a/bnet@v1.23.2: invalid version: resolves to version v1.23.3-0.20211228052159-f6eb15780412 (v1.23.2 is not a tag)(wantbase=v1.23.3-0.20211228052159-f6eb15780412)

statBase = v1.23.2
base = v1.23.3-0.20211228052159-f6eb15780412

go mod download -x mydomain.com/a/bnet@v1.23.13 :

go mod download: imydomain.com/a/bnet@v1.23.13: invalid version: resolves to version v1.23.15-0.20220221055748-c5a5cd77b294 (v1.23.13 is not a tag)(wantbase=v1.23.15-0.20220221055748-c5a5cd77b294)

statBase = v1.23.13
base = v1.23.15-0.20220221055748-c5a5cd77b294

@bcmills
Copy link
Member

@bcmills bcmills commented Feb 23, 2022

Right, the question is, why are we ending up with a pseudo-version for v instead of the requested version? (It must be that the tags are not being reported by the Tags method of the codehost.Repo, but why is that?)

@mengzhuo
Copy link
Contributor

@mengzhuo mengzhuo commented Feb 23, 2022

Why the error log shows v1.23.3 instead of v1.23.13 ?
and the canonical version should be v1.23.3-20211228052159-f6eb15780412 (without 0. after v1.23.3-)

@hidu
Copy link
Author

@hidu hidu commented Feb 23, 2022

Why the error log shows v1.23.3 instead of v1.23.13 ? and the canonical version should be v1.23.3-20211228052159-f6eb15780412 (without 0. after v1.23.3-)

my mistake, the log is test with go mod download -x mydomain.com/a/bnet@v1.23.2

@mengzhuo
Copy link
Contributor

@mengzhuo mengzhuo commented Feb 23, 2022

updates:
I can't reproduce this issue by go mod download -x github.com/rsc/vgotest1@v1.0.1 (v0.0.1 has the same hash with v1.0.1)


Ok, I think the root cause is: multiple tags has same revision and the revToRev using "local cache" to reverse "rev->tag".

Could you drop these lines?

c := r.statCache.Do(rev, func() any {
info, err := r.stat(rev)
return cached{info, err}
}).(cached)
return c.info, c.err

and change into

return r.stat(rev)

reinstall go by execute twice go install cmd/go and fetch again?

@bcmills
Copy link
Member

@bcmills bcmills commented Feb 23, 2022

@hidu, are the versions you're pasting above the exact versions from the tags, or are they redacted? If the version has a build-metadata suffix (like v1.23.13+build20220222), I think that could cause the behavior you're seeing.

@bcmills
Copy link
Member

@bcmills bcmills commented Feb 24, 2022

@hidu, one more thought. When you ran git ls-remote to verify the tags, was that in a git client set up using the same commands that go mod download is executing? I wonder if there is some local change to your clone of the repo that is allowing it to fetch tags that are somehow hidden from the copy in the module cache.

Could you try stepping through those git commands individually and checking that the outputs are correct?

@bcmills bcmills added the WaitingForInfo label Feb 24, 2022
@bcmills bcmills removed this from the Go1.18 milestone Feb 24, 2022
@bcmills bcmills added this to the Go1.19 milestone Feb 24, 2022
@hidu
Copy link
Author

@hidu hidu commented Feb 24, 2022

@bcmills

there is no suffix in the tag, see #51312 (comment)

was that in a git client set up using the same commands that go mod download is executing

same git client

Could you try stepping through those git commands individually and checking that the outputs are correct?

I've checked it, the results are all right

I'm debugging too

witth func:

func (r *codeRepo) convert(info *codehost.RevInfo, statVers string) (*RevInfo, error) 

go1.16.13, go1.16.14 all have the same input:

info={
    "Name": "c5a5cd77b294b44c5b1321d8d4c24fa5406dc5e7",
    "Short": "c5a5cd77b294",
    "Version": "c5a5cd77b294b44c5b1321d8d4c24fa5406dc5e7",
    "Time": "2022-02-21T05:57:48Z",
    "Tags": [
        "refs/tags/v1.23.13",     
        "refs/tags/v1.23.14"    
    ]
}

statVers=v1.23.13

@bcmills
Copy link
Member

@bcmills bcmills commented Feb 24, 2022

Yeah, the tags returned by the Tags method definitely shouldn't still have the refs/tags/ prefix. It's explicitly stripped out here:
https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/modfetch/codehost/git.go;l=229-238;drc=master

@hidu
Copy link
Author

@hidu hidu commented Feb 24, 2022

updates: I can't reproduce this issue by go mod download -x github.com/rsc/vgotest1@v1.0.1 (v0.0.1 has the same hash with v1.0.1)

Ok, I think the root cause is: multiple tags has same revision and the revToRev using "local cache" to reverse "rev->tag".

Could you drop these lines?

c := r.statCache.Do(rev, func() any {
info, err := r.stat(rev)
return cached{info, err}
}).(cached)
return c.info, c.err

and change into

return r.stat(rev)

reinstall go by execute twice go install cmd/go and fetch again?

@mengzhuo
not work

@hidu
Copy link
Author

@hidu hidu commented Feb 24, 2022

i found it @bcmills
https://github.com/golang/go/blob/go1.16.14/src/cmd/go/internal/modfetch/codehost/git.go#L437-L469

git -c log.showsignature=false log -n1 '--format=format:%H %ct %D' c5a5cd77b294b44c5b1321d8d4c24fa5406dc5e7 --

withlog.decorate = full, Output:

c5a5cd77b294b44c5b1321d8d4c24fa5406dc5e7 1645423068 grafted, tag: refs/tags/v1.23.14, tag: refs/tags/v1.23.13

without log.decorate = full, output:

c5a5cd77b294b44c5b1321d8d4c24fa5406dc5e7 1645423068 grafted, tag: v1.23.14, tag: v1.23.13

but only support like this:

ede458df7cd0fdca520df19a33158086a8a68e81 1523994202 HEAD -> master, tag: v1.2.4-annotated, tag: v1.2.3, origin/master, origin/HEAD

@bcmills
Copy link
Member

@bcmills bcmills commented Feb 24, 2022

Neato! Thinking about how to fix it — by any chance, do you have the log.decorate configuration option set in your global .gitconfig?

(We're constantly running into issues from unanticipated formatting options leaked from user's global configs. 😩)

@hidu
Copy link
Author

@hidu hidu commented Feb 24, 2022

Neato! Thinking about how to fix it — by any chance, do you have the log.decorate configuration option set in your global .gitconfig?

(We're constantly running into issues from unanticipated formatting options leaked from user's global configs. 😩)

yes, i have:

[log]
	decorate = full

@mengzhuo
Copy link
Contributor

@mengzhuo mengzhuo commented Feb 24, 2022

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 24, 2022

Change https://go.dev/cl/387835 mentions this issue: cmd/go: fix unexpected "v1.x.y is not a tag" after update to Go 1.16.14

@bcmills bcmills removed the WaitingForInfo label Feb 24, 2022
@bcmills bcmills removed this from the Go1.19 milestone Feb 24, 2022
@bcmills bcmills added this to the Go1.18 milestone Feb 24, 2022
@bcmills
Copy link
Member

@bcmills bcmills commented Feb 24, 2022

@gopherbot, please backport to Go 1.16 and 1.17. This causes erroneous error messages (which may be confusing for users), and the underlying cause is not easy to diagnose.

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 24, 2022

Backport issue(s) opened: #51350 (for 1.16), #51351 (for 1.17).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

@bcmills bcmills added the NeedsFix label Feb 24, 2022
@gopherbot gopherbot removed the NeedsInvestigation label Feb 24, 2022
@gopherbot
Copy link

@gopherbot gopherbot commented Feb 24, 2022

Change https://go.dev/cl/387917 mentions this issue: cmd/go/internal/modfetch: simplify handling of weird version tags

@bcmills bcmills changed the title cmd/go: unexpected "v1.x.y is not a tag" after update to Go 1.16.14 cmd/go: "v1.x.y is not a tag" when .gitconfig sets log.decorate to full Feb 24, 2022
@heschi heschi removed this from the Go1.18 milestone Mar 15, 2022
@heschi heschi added this to the Go1.19 milestone Mar 15, 2022
@leszekgruchala
Copy link

@leszekgruchala leszekgruchala commented Apr 25, 2022

For 3 weeks I was wondering what happened that I started to have timeouts and errors on GO dependency resolution. All because of git configuration... Removing log.decorate = full fixed the issue for me.

gopherbot pushed a commit that referenced this issue May 10, 2022
This fixes an obscure bug in 'go list -versions' if the repo contains
a tag with an explicit "+incompatible" suffix. However, I've never
seen such a repo in the wild; mostly it's an attempt to wrap my brain
around the code and simplify things a bit for the future.

Updates #51324
Updates #51312

Change-Id: I1b078b5db36470cf61aaa85b5244c99b5ee2c842
Reviewed-on: https://go-review.googlesource.com/c/go/+/387917
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GoCommand modules NeedsFix
Projects
None yet
Development

No branches or pull requests

8 participants