git + go - how to handle subprojects with go get

Question

I use the version control system git for my software. And "within" the source code, I use go get to automatically fetch software from github. How can I handle the "double git" situation?

When I run git add on the directory src/github.com/somename/someproject, which is a git repository in itself, will this add anything? (it doesn't look like this when I run git status)

Should I use git submodule for the git get added subdirectories?

What is the best practice in this situation?

---

Edit: I do have a custom $GOPATH environment for my software project. This is why the src/github.com/somename/someproject directory is found inside my software directory hierarchy.

Answer 1

While @nemo's answer is probably the way to go, this is what I did: I stripped the .git and .gitignore files from the go get downloaded repositories. The source path I have is inside my source directory: GOPATH=.../myproject/src/go/. That way all the go get downloads are inside my project tree and I can just handle it with git.

I think that this is what "goven" (see my comment on my question) is supposed to do, but I wasn't able to get it to work.

Answer 2

If you want to store the revision of the foreign packages you use, it would be best if the go import remote syntax would support something like github.com/user/project/sub/directory/revision, which it doesn't unfortunately. There's a discussion on the golang-nuts mailing list about this very topic, check it out for possible solutions and caveats.

The simplest way to do this, is probably to fork the projects you use and import your forks, so you have full control over updates. Platforms like github make it really easy to do so.

From go help remote:

New downloaded packages are written to the first directory listed in the GOPATH environment variable (see 'go help gopath').

So your proposed submodule solution is possible but is not as easy to use, as you have to specify a custom GOPATH while fetching. I would recommend forking the library and referencing the fork.