ARTICLE AD BOX
If you are using go modules. You could use replace directive
The replace directive allows you to supply another import path that might be another module located in VCS (GitHub or elsewhere), or on your local filesystem with a relative or absolute file path. The new import path from the replace directive is used without needing to update the import paths in the actual source code.
So you could do below in your go.mod file
module some-project go 1.12 require ( github.com/someone/repo v1.20.0 ) replace github.com/someone/repo => github.com/you/repo v3.2.1where v3.2.1 is tag on your repo. Also can be done through CLI
go mod edit -replace="github.com/someone/[email protected]=github.com/you/[email protected]"8 Comments
worked great. i think the only reason this doesn't have more upvotes is because folks are not using go modules yet. I also used this trick to point to a file location to another directory on my workstation where i had local edits i was working on. I would just remove my "replace" line once i push my local edits in github.
2019-08-30T13:45:26.33Z+00:00
To handle pull requests
fork a repository github.com/someone/repo to github.com/you/repo download original code: go get github.com/someone/repo be there: cd "$(go env GOPATH)/src"/github.com/someone/repo enable uploading to your fork: git remote add myfork https://github.com/you/repo.git upload your changes to your repo: git push myforkhttp://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html
To use a package in your project
3 Comments
One way to solve it is that suggested by Ivan Rave and http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html -- the way of forking.
Another one is to workaround the golang behavior. When you go get, golang lays out your directories under same name as in the repository URI, and this is where the trouble begins.
If, instead, you issue your own git clone, you can clone your repository onto your filesystem on a path named after the original repository.
Assuming original repository is in github.com/awsome-org/tool and you fork it onto github.com/awesome-you/tool, you can:
cd $GOPATH mkdir -p {src,bin,pkg} mkdir -p src/github.com/awesome-org/ cd src/github.com/awesome-org/ git clone [email protected]:awesome-you/tool.git # OR: git clone https://github.com/awesome-you/tool.git cd tool/ go get ./...golang is perfectly happy to continue with this repository and doesn't actually care some upper directory has the name awesome-org while the git remote is awesome-you. All import for awesome-org are resovled via the directory you have just created, which is your local working set.
In more length, please see my blog post: Forking Golang repositories on GitHub and managing the import path
edit: fixed directory path
2 Comments
I agree this is the "best" solution for this. But it would be really nice to see how people manage this workflow when running the Go app in a Docker container. I am learning golang and wanted to add a tiny feature to a library I am using when I ran into this headache with testing it before creating a Pull Request.
2016-07-18T16:20:21.42Z+00:00
If your fork is only temporary (ie you intend that it be merged) then just do your development in situ, eg in $GOPATH/src/launchpad.net/goamz.
You then use the features of the version control system (eg git remote) to make the upstream repository your repository rather than the original one.
It makes it harder for other people to use your repository with go get but much easier for it to be integrated upstream.
In fact I have a repository for goamz at lp:~nick-craig-wood/goamz/goamz which I develop for in exactly that way. Maybe the author will merge it one day!
answered Jan 15, 2013 at 22:34
54.4k13 gold badges131 silver badges138 bronze badges
2 Comments
Here's a way to that works for everyone:
Use github to fork to "my/repo" (just an example):
go get github.com/my/repo cd ~/go/src/github.com/my/repo git branch enhancement rm -rf . go get github.com/golang/tools/cmd/gomvpkg/… gomvpkg <<oldrepo>> ~/go/src/github.com/my/repo git commitRepeat each time when you make the code better:
git commit git checkout enhancement git cherry-pick <<commit_id>> git checkout masterWhy? This lets you have your repo that any go get works with. It also lets you maintain & enhance a branch that's good for a pull request. It doesn't bloat git with "vendor", it preserves history, and build tools can make sense of it.
6,1861 gold badge51 silver badges57 bronze badges
Instead of cloning to a specific location, you can clone wherever you want. Then, you can run a command like this, to have Go refer to the local version:
go mod edit -replace github.com/owner/repo=../repoThe answer to this is that if you fork a repo with multiple packages you will need to rename all the relevant import paths. This is largely a good thing since you've forked all of those packages and the import paths should reflect this.
8 Comments
I burned more time than I care to admit diagnosing this in my first contribution to a Go project. "All tests pass, including the ones I wrote to exhaustively test new functionality. What's wrong?!" Are you aware of any available tooling to ease this stumbling point for beginners?
2014-05-30T16:37:29.36Z+00:00
@JakeMitchell gomvpkg can do the renames easier/better. go get golang.org/x/tools/cmd/gomvpkg then gomvpkg -help.
2015-03-20T17:06:04.727Z+00:00
Is this still how Go-lang is working? This is just so insane, that it is not funny... Either be upstream-friendly, or downstream-friendly, but not both. It is a huge design flaw in my not so humble opinion, probably done by people who doesn't collaborate too much cross-projects. #FAIL #GOLANG
2016-07-15T12:41:02.04Z+00:00
Since Go 1.18, you can use Go Workspace for this use case.
Run the command
$ go work init path-to-your-fork path-to-your-app-moduleor directly edit
go.work
go 1.18 use ( ./path-to-your-fork ./path-to-your-app-module )The paths here refer to the location of the local copy in your computer.
(The existing answers mentioned `replace`, but with some critical version part missing. Hence this answer)
If the repo is already v1 or higher, then when replace in `go.mod`, you need specify big version of original repo, and both big & specific version of your forked repo.
Format:
replace path/to/orignal_repo/v? => path/to/fork_repo/v? vx.y.z
Repace v? to big versions, replace vx.y.z with your specific version.
e.g:
replace github.com/k0kubun/pp/v3 => github.com/kuchaguangjie/pp/v3 v3.6.025.9k26 gold badges171 silver badges232 bronze badges
The modern answer (go 1.15 and higher, at least).
go mod init github.com/theirs/repoMake an explicit init arg that is the ORIGINAL package names. If you don't include the repo name, it will assume the one in gopath. But when you use go modules, they no longer care where they are on disk, or where git actually pulls dependencies from.
To automate this process, I wrote a small script. You can find more details on my blog to add a command like "gofork" to your bash.
function gofork() { if [ $# -ne 2 ] || [ -z "$1" ] || [ -z "$2" ]; then echo 'Usage: gofork yourFork originalModule' echo 'Example: gofork github.com/YourName/go-contrib github.com/heirko/go-contrib' return fi echo "Go get fork $1 and replace $2 in GOPATH: $GOPATH" go get $1 go get $2 currentDir=$PWD cd $GOPATH/src/$1 remote1=$(git config --get remote.origin.url) cd $GOPATH/src/$2 remote2=$(git config --get remote.origin.url) cd $currentDir rm -rf $GOPATH/src/$2 mv $GOPATH/src/$1 $GOPATH/src/$2 cd $GOPATH/src/$2 git remote add their $remote2 echo Now in $GOPATH/src/$2 origin remote is $remote1 echo And in $GOPATH/src/$2 their remote is $remote2 cd $currentDir } export -f goforkin your Gopkg.toml file add these block below
[[constraint]] name = "github.com/globalsign/mgo" branch = "master" source = "github.com/myfork/project2"So it will use the forked project2 in place of github.com/globalsign/mgo








