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

hidu · 2022-02-22T09:47:48Z

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?

repo mydomain.com/a/bnet has tag v1.23.13.
repo mydomain.com/a/bnet download direct：GONOPROXY="*mydomain.com*"
repo mydomain.com/myapp require mydomain.com/a/bnet@v1.23.13
clean mod cache: go clean -modcache
cd mydomain.com/myapp
exec go version,output: go version go1.16.14 darwin/amd64
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)

with go1.16.13, exec go1.16.13 mod download ,there is no error, download success
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?

The text was updated successfully, but these errors were encountered:

dmitshur · 2022-02-22T14:51:57Z

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).

hidu · 2022-02-23T02:22:26Z

v1.23.13 is a tag, not branch.

dmitshur · 2022-02-23T02:41:58Z

@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.

bcmills · 2022-02-23T02:51:26Z

@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 · 2022-02-23T02:52:31Z

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 · 2022-02-23T02:55:51Z

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

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

bcmills · 2022-02-23T03:09:32Z

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 · 2022-02-23T03:30:32Z

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 · 2022-02-23T04:05:15Z

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 · 2022-02-23T04:15:50Z

go1.18rc1 also reproduced

hidu · 2022-02-23T04:21:12Z

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 · 2022-02-23T04:43:05Z

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 · 2022-02-23T05:03:25Z

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 · 2022-02-23T05:23:32Z

--- 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 · 2022-02-23T05:56:28Z

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 · 2022-02-23T06:53:51Z

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 · 2022-02-23T07:07:17Z

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 · 2022-02-23T07:41:28Z

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?

go/src/cmd/go/internal/modfetch/codehost/git.go

Lines 506 to 510 in 3517036

    
           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 · 2022-02-23T18:42:41Z

@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 · 2022-02-24T02:14:10Z

@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 · 2022-02-24T17:18:26Z

@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 · 2022-02-24T17:24:32Z

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.

gopherbot · 2022-02-24T21:17:20Z

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

leszekgruchala · 2022-04-25T14:34:55Z

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.

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>

lukasmalkmus · 2022-05-30T15:24:24Z

I'm seeing this error, too, but I don't have log.decorate set to full (as reported by git config log.decorate in my module). I tagged v0.10.0-rc.2. When everything went fine, I tagged v0.10.0. Now go get reports the error discussed here:

$ go get github.com/axiomhq/axiom-go/axiom@v0.10.0
go: github.com/axiomhq/axiom-go/axiom@v0.10.0: github.com/axiomhq/axiom-go@v0.10.0: invalid version: resolves to version v0.10.0-rc.2 (v0.10.0 is not a tag)

This is on a machine I just set up from scratch and I'm trying to figure out the issue as this workflow has previously worked fine for me.

Git version is git version 2.36.1.

bcmills · 2022-05-30T16:10:31Z

@lukasmalkmus, please file a separate issue with steps to reproduce.

ianlancetaylor · 2022-06-24T20:36:33Z

@bcmills This issue is in the 1.19 milestone but I can't tell what the status is. Is there more to do here? Thanks.

bcmills · 2022-06-28T18:20:02Z

This has a fix CL pending Googler review; it should also be backported to Go 1.18 and 1.17 once the fix is merged.

gopherbot · 2022-06-28T19:51:19Z

Change https://go.dev/cl/414874 mentions this issue: [release-branch.go1.18] cmd/go: pass --no-decorate when listing git tags for a commit

gopherbot · 2022-06-28T19:51:52Z

Change https://go.dev/cl/414875 mentions this issue: [release-branch.go1.18] cmd/go: pass --no-decorate when listing git tags for a commit

…ags for a commit This avoids a parse error when the user's global .gitconfig sets log.decorate to true. Updates #51312. Fixes #51351. Change-Id: Ic47b0f604c0c3a404ec50d6e09f4e138045ac2f2 Reviewed-on: https://go-review.googlesource.com/c/go/+/387835 Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> (cherry picked from commit a30f434) Reviewed-on: https://go-review.googlesource.com/c/go/+/414875

…ags for a commit This avoids a parse error when the user's global .gitconfig sets log.decorate to true. Updates #51312. Fixes #53588. Change-Id: Ic47b0f604c0c3a404ec50d6e09f4e138045ac2f2 Reviewed-on: https://go-review.googlesource.com/c/go/+/387835 Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> (cherry picked from commit a30f434) Reviewed-on: https://go-review.googlesource.com/c/go/+/414874

…ags for a commit This avoids a parse error when the user's global .gitconfig sets log.decorate to true. Updates golang#51312. Fixes golang#53588. Change-Id: Ic47b0f604c0c3a404ec50d6e09f4e138045ac2f2 Reviewed-on: https://go-review.googlesource.com/c/go/+/387835 Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> (cherry picked from commit a30f434) Reviewed-on: https://go-review.googlesource.com/c/go/+/414874

This avoids a parse error when the user's global .gitconfig sets log.decorate to true. Fixes golang#51312. Change-Id: Ic47b0f604c0c3a404ec50d6e09f4e138045ac2f2 Reviewed-on: https://go-review.googlesource.com/c/go/+/387835 Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

seankhliao added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Feb 22, 2022

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 added GoCommand cmd/go NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Feb 23, 2022

bcmills self-assigned this Feb 23, 2022

bcmills added modules and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Feb 23, 2022

bcmills added this to the Go1.18 milestone Feb 23, 2022

bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Feb 24, 2022

bcmills removed this from the Go1.18 milestone Feb 24, 2022

This was referenced Feb 24, 2022

cmd/go: "v1.x.y is not a tag" when .gitconfig sets log.decorate to full [1.16 backport] #51350

Closed

cmd/go: "v1.x.y is not a tag" when .gitconfig sets log.decorate to full [1.17 backport] #51351

Closed

bcmills added the NeedsFix The path to resolution is known, but the work has not been done. label Feb 24, 2022

gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 24, 2022

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

mengzhuo mentioned this issue Feb 28, 2022

cmd/go: go get private_module@version_tag fails if the same commit has been downloaded with pseudo-version previously (before being tagged) #51374

Closed

heschi modified the milestones: Go1.18, Go1.19 Mar 15, 2022

pboguslawski mentioned this issue Jun 2, 2022

Invalid github.com/go-delve/liner version go-delve/delve#3025

Closed

bcmills mentioned this issue Jun 28, 2022

cmd/go: "v1.x.y is not a tag" when .gitconfig sets log.decorate to full [1.18 backport] #53588

Closed

gopherbot closed this as completed in a30f434 Jun 28, 2022

central182 mentioned this issue Jul 19, 2022

cmd/go: spurious "v1.x.y is not a tag" error when a tag's commit was previously download without the tag #53955

Closed

golang locked and limited conversation to collaborators Jun 28, 2023

gopherbot added the FrozenDueToAge label Jun 28, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

hidu commented Feb 22, 2022 •

edited

dmitshur commented Feb 22, 2022

hidu commented Feb 23, 2022

dmitshur commented Feb 23, 2022 •

edited

bcmills commented Feb 23, 2022 •

edited

hidu commented Feb 23, 2022

hidu commented Feb 23, 2022

bcmills commented Feb 23, 2022

hidu commented Feb 23, 2022 •

edited

bcmills commented Feb 23, 2022

hidu commented Feb 23, 2022 •

edited

hidu commented Feb 23, 2022

bcmills commented Feb 23, 2022

hidu commented Feb 23, 2022

hidu commented Feb 23, 2022 •

edited

bcmills commented Feb 23, 2022

mengzhuo commented Feb 23, 2022 •

edited

hidu commented Feb 23, 2022

mengzhuo commented Feb 23, 2022 •

edited

bcmills commented Feb 23, 2022

bcmills commented Feb 24, 2022

bcmills commented Feb 24, 2022

gopherbot commented Feb 24, 2022

gopherbot commented Feb 24, 2022

leszekgruchala commented Apr 25, 2022

lukasmalkmus commented May 30, 2022 •

edited

bcmills commented May 30, 2022

ianlancetaylor commented Jun 24, 2022

bcmills commented Jun 28, 2022

gopherbot commented Jun 28, 2022

gopherbot commented Jun 28, 2022

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

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

Comments

hidu commented Feb 22, 2022 • edited

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

dmitshur commented Feb 22, 2022

hidu commented Feb 23, 2022

dmitshur commented Feb 23, 2022 • edited

bcmills commented Feb 23, 2022 • edited

hidu commented Feb 23, 2022

hidu commented Feb 23, 2022

bcmills commented Feb 23, 2022

hidu commented Feb 23, 2022 • edited

bcmills commented Feb 23, 2022

hidu commented Feb 23, 2022 • edited

hidu commented Feb 23, 2022

bcmills commented Feb 23, 2022

hidu commented Feb 23, 2022

hidu commented Feb 23, 2022 • edited

bcmills commented Feb 23, 2022

mengzhuo commented Feb 23, 2022 • edited

hidu commented Feb 23, 2022

mengzhuo commented Feb 23, 2022 • edited

bcmills commented Feb 23, 2022

bcmills commented Feb 24, 2022

bcmills commented Feb 24, 2022

gopherbot commented Feb 24, 2022

gopherbot commented Feb 24, 2022

leszekgruchala commented Apr 25, 2022

lukasmalkmus commented May 30, 2022 • edited

bcmills commented May 30, 2022

ianlancetaylor commented Jun 24, 2022

bcmills commented Jun 28, 2022

gopherbot commented Jun 28, 2022

gopherbot commented Jun 28, 2022

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

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

hidu commented Feb 22, 2022 •

edited

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

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

dmitshur commented Feb 23, 2022 •

edited

bcmills commented Feb 23, 2022 •

edited

hidu commented Feb 23, 2022 •

edited

hidu commented Feb 23, 2022 •

edited

hidu commented Feb 23, 2022 •

edited

mengzhuo commented Feb 23, 2022 •

edited

mengzhuo commented Feb 23, 2022 •

edited

lukasmalkmus commented May 30, 2022 •

edited