does not match short name of revision (expected %s)

Error message

does not match short name of revision (expected %s)

What it means

Default branch of the same hash comparison in validatePseudoVersion (coderepo.go:694-703). Neither the embedded rev nor info.Short is a prefix of the other, so the commit named by the pseudo-version simply is not the commit the VCS reports at that revision. The pseudo-version names a different commit than the one actually fetched.

Source

Thrown at src/cmd/go/internal/modfetch/coderepo.go:701

					err = &module.InvalidVersionError{Version: version, Pseudo: true, Err: err}
				}
				err = &module.ModuleError{Path: r.modPath, Err: err}
			}
		}
	}()

	rev, err := module.PseudoVersionRev(version)
	if err != nil {
		return err
	}
	if rev != info.Short {
		switch {
		case strings.HasPrefix(rev, info.Short):
			return fmt.Errorf("revision is longer than canonical (expected %s)", info.Short)
		case strings.HasPrefix(info.Short, rev):
			return fmt.Errorf("revision is shorter than canonical (expected %s)", info.Short)
		default:
			return fmt.Errorf("does not match short name of revision (expected %s)", info.Short)
		}
	}

	t, err := module.PseudoVersionTime(version)
	if err != nil {
		return err
	}
	if !t.Equal(info.Time.Truncate(time.Second)) {
		return fmt.Errorf("does not match version-control timestamp (expected %s)", info.Time.UTC().Format(module.PseudoVersionTimestampFormat))
	}

	tagPrefix := ""
	if r.codeDir != "" {
		tagPrefix = r.codeDir + "/"
	}

	// A pseudo-version should have a precedence just above its parent revisions,
	// and no higher. Otherwise, it would be possible for library authors to "pin"

View on GitHub (pinned to b6b368adc5)

Solutions

Re-derive the pseudo-version from the current commit: `go get <module>@<branch-or-tag>` and let the toolchain compute it.
If upstream rewrote history, `go clean -modcache` and re-resolve; coordinate with upstream about force-pushes.
Verify the commit hash actually exists in the source repo (`git cat-file -e <hash>^{commit}`).

Example fix

// before (hash does not match fetched commit)
require example.com/m v0.0.0-20240101120000-e3702bed3d42

// after
require example.com/m v0.0.0-20240101120000-a1b2c3d4e5f6   // correct hash for the intended commit

Defensive patterns

Strategy: validation

Validate before calling

// Confirm the embedded hash still exists and matches the fetched commit.
// bash:
//   git cat-file -e <embedded-hash>^{commit} || echo "hash missing"
//
// In CI, after `go mod download`, verify go.sum entries match upstream:
//   go mod verify

Prevention

Treat upstream force-pushes/rebases as breaking changes; re-derive pseudo-versions.
Pin to tags rather than commits when history is volatile.
Run `go mod verify` in CI to catch checksum/history mismatches.

When it happens

Trigger: A pseudo-version was copied from a different module/branch/fork; the VCS rewrote history (rebase/force-push) so the hash now points elsewhere or no longer exists; a proxy served a zip whose head commit differs from the recorded pseudo-version metadata.

Common situations: Force-pushed upstream branches; squashed-merge workflows that invalidate old commit hashes; copy-paste errors between dependencies; mismatched go.sum entries after a upstream rewrite.

Related errors

AI-assisted analysis of golang/go@b6b368adc5 (2026-08-12). Data as JSON: /api/errors/94b5bf8b691cacd6. Report an issue: GitHub.