CODEWITHSUNDEEP
gitgogit-branchgo-modulesgit-tag
vignz.pie
vignz.pie

Reputation: 309

How do I make commit hash consumable on top of latest tag for go get command?

I'm working with the framework package (github.com/username/fmk) and I'm facing an issue with version resolution using go get.

Current Release Process:

  1. Feature Branches: Developers create isolated branches from development to work on new features.
  2. Merge to Development: Once features are complete and tested, they're integrated back into the development branch.
  3. Pre-Release Branch: For all releases, a dedicated pre-release branch is created from latest development for final testing before merging to main.
  4. Main Branch & Tag: Pre-release branch is merged into the main branch. A corresponding version tag is marked at the main branch after merge.

Problem: I'm trying to install a specific commit from a feature branch using go get. Here's the command I used:

go get github.com/username/fmk@066bca62e82a

However, go get attempts to install version v1.30.1 of the package. This version doesn't seem to exist according to the tags in the repository. When I checked the commits around the time v1.30.0 was tagged, I found a merge from main to development. I'm guessing this has to do with falling back to next version of v1.30.0. I'm nit sure though.

Expected Behavior: I expected go get to download and install the package corresponding to the commit hash (066bca62e82a). On top of the latest version tag which is v1.44.2.

Things I've Tried:

Tried forcing version with timestamp:

> go get -d github.com/username/[email protected]
go: github.com/username/[email protected]: invalid pseudo-version: revision 066bca62e82a is not a descendent of preceding tag (v1.44.1)

Tried removing (@none) the package and installing it again:

> go get -d github.com/username/fmk@none
> go get -d github.com/username/fmk@066bca62e82a

#response:
    go: downloading github.com/username/fmk v1.30.1-0.20240423064250-066bca62e82a
    go: github.com/username/fmk@066bca62e82a: github.com/username/[email protected]: verifying module: github.com/username/[email protected]: reading https://sum.golang.org/lookup/github.com/username/[email protected]: 404 Not Found
            server response:
            not found: github.com/username/[email protected]: invalid version: git ls-remote -q origin in /tmp/gopath/pkg/mod/cache/vcs/6ad280b7d82bf06e4410b8adbf3bd0e2922d5dc1e17a71a955f977917d4be5da: exit status 128:
                    fatal: could not read Username for 'https://github.com': terminal prompts disabled
            Confirm the import path was entered correctly.
            If this is a private repository, see https://golang.org/doc/faq#git_https for additional information.

Question:

Upvotes: -2

Views: 141

Answers (1)

eik
eik

Reputation: 4610

According to “Managing dependencies: Getting a specific commit using a repository identifier” go get example.com/theirmodule@4cf76c2 should work.

Let's try:

> go get go.uber.org/goleak@7f1444f                                 
go: added go.uber.org/goleak v1.3.1-0.20240605195212-7f1444f09263
> fgrep go.uber.org/goleak go.mod
    go.uber.org/goleak v1.3.1-0.20240605195212-7f1444f09263 // indirect

so this works, and we get exactly the 7f1444f version (which is not @latest) as expected, check the source at $(go env GOMODCACHE)/go.uber.org/[email protected]. The v1.3.1 you are seeing here is part of the pseudo-version, which is “a base version prefix (vX.0.0 or vX.Y.Z-0), which is either derived from a semantic version tag that precedes the revision or vX.0.0 ”:

vX.Y.(Z+1)-0.yyyymmddhhmmss-abcdefabcdef is used when the base version is a release version like vX.Y.Z. For example, if the base version is v1.2.3, a pseudo-version might be v1.2.4-0.20191109021931-daa7c04131f5.

Looks good to me, and is well documented - the link above contains a discussion why pseudo-versions make sense:

These forms give pseudo-versions two useful properties:

  • Pseudo-versions with known base versions sort higher than those versions but lower than other pre-release for later versions.
  • Pseudo-versions with the same base version prefix sort chronologically.

In your case it seems that you are checking out a feature branch that's working from v1.30.0 towards v1.30.1 or later, so you get something that sorts before v1.30.1 but after v1.30.0. Is this what's happening in your case?

Otherwise I don't know the structure of your repository well enough to comment on it, so I can only speculate that you are developing on a branch that doesn't contain the latest version tag (“I found a merge from main to development. I'm guessing this has to do with falling back to next version of v1.30.0.”), so technically you might not work “on top of the latest version tag which is v1.44.2”, only on top of a long living development branch that is very similar to your release branch, but is technically still based on v1.30.0. This might be its own can of worms, but has more to do with a git branching culture than with Go.

What you could do is tag your development branch with a pre-release version like v1.44.3-dev (or v1.44.3-alpha.1) after merging into the release branch, so that you are more accurately know what you are working on. Then you get:

vX.Y.Z-pre.0.yyyymmddhhmmss-abcdefabcdef is used when the base version is a pre-release version like vX.Y.Z-pre.

This would also enable your non-release programs to more accurately report a git development version than currently possible.

Also be aware that “more than one pseudo-version may refer to the same commit”, so you do not break anything by retroactively tagging.

Upvotes: 0

Related Questions