Transferring a Go repository and installing old releases

[Tiago de Bem Natel de Moura]

Hi,

I'd like to transfer a Go repository to another Github organization but somehow make the "go install" still able to install the old releases using the new import path. Is this possible?

I did the transfer using the Github UI, and updated the go.mod and all imports to use the new project path, but now I'm unable to install the existing releases using the new import path.

Example:

works: go install github.com/old/project/c...@v1.0.0

The "github.com/old/project" repository now automatically redirects to "github.com/new/project" (Github Feature).

But this fails: go install github.com/new/project/c...@v1.0.0

error below:

go: github.com/new/project/c...@v1.0.0: github.com/new/pro...@v1.0.0: parsing go.mod:
module declares its path as: github.com/old/project
        but was required as: github.com/new/project

If I clone the "github.com/new/project" repository then everything works fine (go build, go test, etc) but only "go install" fails...

Is there a solution?

[Brian Candler]

What happens if you change the go.mod file, and all imports within the project, to use github.com/new/project instead of github.com/old/project ?

(If you make this change, the issue then is whether you can still "go install github.com/old/project...")

The reason it works with a local clone is that you can put anything you like in go.mod, even

    module blahdiblah/dontcare

and then do

    import "blahdiblah/dontcare/foo"

within the same local filetree.  The fact that the module name includes "github.com" doesn't require any access to github, if the module name can be found within the local workspace.

[Tiago de Bem Natel de Moura]

Hi Brian,

I updated go.mod and all import paths in the main branch already, but the issue is related to installing releases (with go install) that had the old name in the go.mod.

[Tiago de Bem Natel de Moura]

This is the real project: https://github.com/terramate-io/terramate

It was transferred from https://github.com/mineiros-io/terramate

So my problem is that all existent releases can be installed with "go install" if using the old module name (github.com/mineiros-io/terramate).

This works: go install github.com/mineiros-io/terramate/cmd/terr...@v0.2.18
But this does not: go install github.com/terramate-io/terramate/cmd/terr...@v0.2.18
It gives the error:
go: github.com/terramate-io/terramate/cmd/terr...@v0.2.18: github.com/terramate-io/terr...@v0.2.18: parsing go.mod:
module declares its path as: github.com/mineiros-io/terramate
        but was required as: github.com/terramate-io/terramate

I'm wondering, why?

From the proxy, it retrieves the modfile containing the (correct) old module name:
https://proxy.golang.org/github.com/terramate-io/terramate/@v/v0.2.18.mod

And downloads the zip from: https://proxy.golang.org/github.com/terramate-io/terramate/@v/v0.2.18.zip

But go install is picky and disallow the installation.

It fails at this line: https://github.com/golang/go/blob/055c186f53493da473c888869ad468861ba25f1a/src/cmd/go/internal/modload/modfile.go#L643

But if I manually unpack the v0.2.18 zip, cd into and run "go build", "go install", etc, everything works...

If this is the intended behavior, can someone explain the reasoning behind it?

So is it that the only option here is documenting to our users that releases before v0.2.19 need to be installed with the old module name (if using go install) ?

[Brian Candler]

Ah, I think I see the problem.

github.com/terramate-io/terramate/cmd/terr...@v0.2.18

refers to the tag v0.2.18 - and at that point, go.mod had not been updated. (Try "git checkout v0.2.18; head go.mod")

You *could* rewrite history globally to make it believe that it had been terramate-io/terramate since day one.

But I don't know if anyone has any better ideas.