1

I have the complete src-tree of a go / golang project in a git repository. This so I can easily clone a complete project and its dependencies to a different computer.

When using go get from e.g., github.com, go clones the github project inside my src-tree.

Is there an easy / standard approach for converting this inner git repo into a submodule? Something similar to git submodule add <path>?

Or do I have to, manually or automatically, find the url to the inner repository and use git submodule add <url> <path>

Any arguments for NOT using this approach? As far as I can see, the advantages are that I have complete control of versioning of the sources, easy cloning of the complete project including dependencies, easy way to update third-part code I depend on / retrieved using go get.

Conclusion Thank you Will C and VonC. I ended up using the vendor system with the tool govendor. I like the tool because of its transparancy and simplicity - it is never a required tool. Also, the Go vendoring system satisifies my main objective - to make it easy to clone my complete project and its dependencies to a different computer.

runec
  • 1,687
  • 12
  • 22

2 Answers2

2

The approach you described seems to cause more headaches for maintenance purposes. Imagine whenever making a change and having to remember to do a git submodule update and then having backwards compatibility issues.

Instead, I would advise taking a look at Godep as a dependency tool. Also, in Go 1.5+, they are already experimenting with a vendor folder for managing dependencies which you can find more information about here.

From a high level, there are some nuances in versioning with Godep but it allows you to effectively check out at a specific commit via its SHA. The SHA is determined by the commit you're on in the actual dependency located in your GOPATH. This effectively also includes the advantages you mentioned such as having one centrally located directory with the dependencies and their dependencies and having the ability to control the version of the dependencies you'd want to use. It comes with much less headache of attempting to manage it in git submodules.

Will C
  • 1,750
  • 10
  • 20
1

I fully agree with Will C's answer, but just in case you still want to reference your github repo as a submodule (in a vendor subfolder), here is a script I made to quickly do just that:

It will:

  • go get the github repo within vendor/src (by resetting temporarily GOPATH to vendor)
  • identify all the repos imported by go get (meaning your github repo and its dependencies), using go list -f
  • add those repos as submodule of your main repo, in a vendor subfolder
  • clean (rm) the vendor/src folder, which was just there to get the repos.

See vendor.bat.

Usage:

cd /path/to/your/repo
vendor github.com/jroimartin/gocui

That will create:

 /path/to/your/repo/vendor/github.com/jroimartin/gocui
 /path/to/your/repo/vendor/github.com/<other/dependent/repos>
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thank you Will C and VonC. I ended up using the vendor system with the tool govendor. I like the tool because of its transparancy and simplicity - it automates the steps I would use manually quite accurately, so it is never a required tool. Also, the vendoring system satisifies my main objective - to make it easy to clone my complete project and its dependencies to a different computer. – runec Apr 27 '16 at 08:43