How does go mod tidy work generate psuedoversions for local directories?

Question

Can go mod tidy generate meaningful commit versions for local git repositories?

Background

I recently noticed that go mod tidy, when run from a local directory, generates a version using the "zero time" value from Golang, like so:

require example.com/db_api v0.0.0-00010101000000-000000000000

This seems reasonable for a local repository with no commits and no version tags... however, when I tried to add commits and tags to a local directory, I noticed that go mod tidy still relied on the zero timestamp as the identifier for the require statement.

Example

Let's start with a dependency:

➜  db_api git:(heads/v1.0.0) tree
.
├── go.mod
└── vars
    └── constants.go

And a main repo:

➜  webapp git:(master) ✗ tree
.
├── go.mod
└── main.go

Now, if I add a create replace directive like so (such that the webapp/main.go depends on the constants.go file in the db_api directory...

replace example.com/db_api => ../db_api

Then the result of go mod tidy will always be the above "zero timestamp", as opposed to v1.0.0.

In contrast, running go mod tidy against a generic "GitHub" repo (i.e. cobra), results in a "tag" based version pin:

require (
        example.com/db_api v0.0.0-00010101000000-000000000000
        github.com/spf13/cobra v1.2.1
)

It seems to me like, the logic associated with remote git repositories (to get the latest semver tag), should be identical even for remote repositories. However, based on my experiments in here, it appears like local repositories aren't inspected for tags.

Hence, the original question... Can go mod tidy guess versioned data from a local repo in the same manner as it would for a remote repository, or is a local git repo fundamentally different in the way it is pinned in a go module?

> Can go mod tidy generate meaningful commit versions for local git repositories?

No

> Hence, the original question... Can go mod tidy guess versioned data from a local repo in the same manner as it would for a remote repository,

No

> or is a local git repo fundamentally different in the way it is pinned in a go module?

Yes.

replace in go.mod means "use those files I dumped there as the module". The fact that you might manage these files with git or rsync or whatnot doesn't matter the slightest.