Problem: there's an awesome Golang project on GitHub which you want to fork. You want to develop & collaborate on that fork, but the golang import path, in your source code, still references the original path, breaking everything.
A couple solutions offered below. First, though, let's get some names.
A sample case, the problem at hand
There's an awesome tool on http://github.com/awsome-org/tool. You successfully fork it onto http://github.com/awesome-you/tool.
You want to collaborate on http://github.com/awesome-you/tool; you wish to pull, commit & push. Maybe you want to send pull requests to the origin.
The following is commonly found throughout .go files in the repository:
import ( "github.com/awesome-org/tool/config" "github.com/awesome-org/tool/driver" "github.com/awesome-org/tool/net" "github.com/awesome-org/tool/util" )
go get http://github.com/awesome-you/tool
golang creates your $GOPATH/src/github.com/awesome-you/tool/, which is awesome. However, as you resolve dependencies via
cd $GOPATH/src/github.com/awesome-you/tool/ ; go get ./...
golang digs into the source code, finds references to github.com/awesome-org/tool/config, github.com/awesome-org/tool/driver etc, and fetches those from http://github.com/awsome-org/tool and onto $GOPATH/src/github.com/awesome-org/tool/, which is not awesome. You actually have two copies of the code, one from your fork, one from the origin, and your own fork will be largely ignored as it mostly points back to the origin.
A bad solution
The dirty, bad solution would be for you to go over the source code and replace "github.com/awesome-org/tool" entries with "github.com/awesome-you/tool". It is bad for two reasons:
- You will not be able to further pull changes from upstream
- You will not be able to pull-request and push your own changes upstream