git submodule vs normal go vendoring

[JM]

can anyone tell me the pros/cons of using git submodule update instead of godep govendor etc... ?

git submodule update --init --recursive

[Peter Mogensen]

Your build depend on that command succeeding.
If sub-repos are not under your control that can be a serious problem
for reproducible build - or builds at all.

/Peter

[paul.to...@gmail.com]

can anyone tell me the pros/cons of using git submodule update instead of godep govendor etc... ?

We used to use git submodules, but have now switched to https://github.com/golang/dep . Much recommended.

Cheers,

Paul 

[Sam Vilain]

In theory, the git submodule builds are *more* reproducible, because all your build servers etc have clones of those sub-repos cached under their .git, even though they are not under your control.

If the upstream goes away, you can just re-publish the repo (which you'll have cloned locally) and adjust the remote URL in .gitmodules.  New people cloning will get the clone from the new source.

That said, submodules have very poor support by many commercial and popular git tools, especially GUI and IDE-based tools.  They don't always behave as you'd expect when switching branches and this can be confusing to the uninitiated.  So you might run into practical problems using them.

Sam

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[paul.to...@gmail.com]

If the upstream goes away, you can just re-publish the repo (which you'll have cloned locally) and adjust the remote URL in .gitmodules.  New people cloning will get the clone from the new source.

Not to counter anything you've said, but dep also allows adjusting the URL. Gopkg.toml:

[[constraint]]
  name = "github.com/some/project"
  source = "github.com/forkof/project"

Cheers,

Paul