Go generate is one of my favorite tools but it is easy to mess up the import paths if you are not careful. This problem generally occurs when the import paths end up referencing to your fork and not to the original repo. This is a very common issue if you are:
- Using go generate
- Collaborating with others over github (essentially having your own fork of the project)
I was working on taskcluster-cli. If you notice carefully, it has a file called
subtree-imports.go which automatically imports subtrees on running
go generate, which means it has import paths like:
If I fork the project and automatically generate imports, it will import a path something like this:
As you can see, the import path generated are different. This is all horribly screwed up now! :(
Let’s dive into the heart of the problem! The import paths get messed up because they depend on where the code is residing. When I clone my fork, the code is now residing at
$GOPATH/src/github.com/nikhita/taskcluster-cli and not at
$GOPATH/src/github.com/taskcluster/taskcluster-cli which leads to…import hell?
So the solution is to make sure that your code resides at
$GOPATH/src/github.com/taskcluster/taskcluster-cli. Wait! Before you freak out and start yelling “I WANT TO MAKE CHANGES AND PUSH TO MY FORK, NOT THE ORIGINAL REPO!”, let’s add some more remotes! :D
Get the names right
If you do a
$ git remote -v at the location where your original repo is, you’ll probably see something like this:
Before adding more remotes, let’s name everything how it should be. Let’s call this remote as upstream. Just do a
$ git remote rename origin upstream.
For a sanity check, let’s
$ git remote -v again:
Phew, we are out of messing up with names now! :)
Adding your fork
Now I’ll add my fork as a remote. Let’s call it origin.
We can see that doing this does us good:
- Now our import paths point to
$GOPATH/src/github.com/taskcluster/taskcluster-cliand not a directory with my fork.
- My import paths will no longer get messy.
- I can still safely make changes and push to my fork (origin).
Read this only if you don’t have a fresh fork i.e. you have made some changes, pushed it to a remote repo (mostly your fork) and now realized that you have to sort out everything. If you a fresh fork, move onto the next section.
To fix this, you can create branches according to your fixes and make these branches track the branches in the remote fork.
- Create a new branch according to your fix. Let’s call the branch my-fix-local.
- If you have previously worked on the fix and pushed it to your forked repo, make the local branch track your remote branch.
- Pull your work from the remote branch
Check the import paths
Now that you have your repo in the right location, with the changes you had made, you can import all your paths again. This time, you’ll see that there would be no conflicts with original import paths and all’s good! :)
Let’s push it!
- Import paths in order? Check.
- Changes present? Check.
- My fork as a remote? Check.
Great, we have everything set up right - let’s push it now! :)
For sending a pull request, you can use Github.
Updating your repo
While you were busy sorting out your import paths, someone else might have contributed some code. To update your repo, you can fetch and merge. I generally don’t like touching
rebase unless necessary but you could also do a
git rebase upstream/master.
And…we are done! :)
Subscribe via RSS