What does glide do that git submodules don't?

[quarnster]

I was under the impression that regular git submodules would work for the GO15VENDOREXPERIMENT support. Any particular reason to use glide instead? It just seems to me like an extra step that then also disables vendored "go get" support...

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/26965914-what-does-glide-do-that-git-submodules-don-t?utm_campaign=plugin&utm_content=tracker%2F15716642&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F15716642&utm_medium=issues&utm_source=github).

[erbridge]

Submodules aren't checked out by go get either. At least with glide, you get the full vendor tree checked out in one command (glide install / glide get). All the other tools I looked at recommended checking in vendor/, which seems pretty nasty to me, but doing that would probably fix vendored go get-ability (at least by my understanding).

[quarnster]

Submodules aren't checked out by go get either.

The documentation says it does:

If the vendoring experiment is enabled (see 'go help gopath'), then when go get checks out or updates a Git repository, it also updates any git submodules referenced by the repository.

as do the code, though I must confess I haven't tried it.

[erbridge]

Oh. I wasn't aware of that. In that case, I agree that we probably don't need glide.

[erbridge]

However, it doesn't appear to work:

$ go get github.com/limetext/lime-backend/lib
# cd .; git --git-dir=/go/path/src/github.com/limetext/lime-backend/.git submodule update --init --recursive
No submodule mapping found in .gitmodules for path 'packages'
package github.com/limetext/lime-backend/lib: exit status 1

[quarnster]

Indeed, and that issue appears to be golang/go#12573. The workaround of go get ... followed by go get -u ... appears to work though.

[erbridge]

Ok, so something glide does that submodules don't is allow you to flatten the hierarchy if packages are used by both the main package and a vendored package. If we have both, go thinks they're different versions (even if they aren't), and throws errors.

[quarnster]

Good point, might want to open up a go bug for that if there isn't one already

[quarnster]

Though I guess the situation isn't obvious if both packages explicitly require different versions of that same package.

[erbridge]

In which case, the importing package should probably get the say over which version to really use. In most cases, you'd expect them to use the same version, though.