README.md

gsv

Table of Contents

Introduction

gsv is the Go Submodule Vendoring tool. It does native
Go vendoring using Git submodules. This approach makes configuration
files redundant and doesn't require additional tooling to build a
gsv-vendored Go project because Git (which you have installed anyway)
is used to track the revisions of your vendored dependencies.

Therefore, in order to fetch and install a Go package that has used
gsv to vendor its dependencies a simple

go get $PACKAGE_URL

will do the job. Go 1.5.X needs some additional steps (see FAQ).

Compared to a copy-based vendoring approach gsv preserves the dependencies'
histories and links them to the main project's history which facilitates
the usage of the Git tool suite. Therefore, it's possible to go through
each dependency's git log and analyze what changes have been done since
the last update. Also, git bisect can be used to find a commit in a
dependency's repository that for example caused the main project to break.
And so on.

Note that pulling in the build- and test-dependencies of your
dependencies is unlikely to fix go build ./... and go test ./...
because the pulled in packages will then have unsatisfied
dependencies. And going all the way down in the recursion doesn't
seem to be the right solution for managing your build- and
test-dependencies.

TODO

In order of priority. Might not be implemented exactly as
suggested here.

Add a -purge flag such that unused vendored submodules will
be detected and removed.

Use code from Go's stdlib instead from gb-vendor

Add a -updateall flag such that all dependencies are
updated to their current origin/master.

Take a look at git2go and see if there is progress in
submodules support.

Look for alternatives for libgit2. This dependency reduces
portability and makes installation a bit harder.