On 7/12/16 1:15 PM, Johann Höchtl wrote: > I use godep. There has been lots of rumour lately to use gb. > > What do others use? > > If there is a blog post available somewhere comparing the pros and > cons, please provide one. > I know https://github.com/golang/go/wiki/PackageManagementTools > > I also like the idea of manul to use git submodules > https://github.com/kovetskiy/manul
I've been using a submodule-based approach (vendetta) for a while now, and IMHO it beats all the non-submodule alternatives. With a submodule, you keep a *complete clone* of the imported dependency and its history. Not just a snapshot which misses the development and copyright history of it. For a long time now, switching branches with a submodule has been completely transparent and fast. It works well with all the git tooling - log, diff, etc. The subproject is handled as a first class entity. The bulky imported files are not included directly in your repository, but you get instead the commit SHA1 of the dependency which precisely specifies the version, for reproducible builds. You can update dependencies just by cd'ing into the directory and using 'git pull', or you can use 'git submodule update -r' - standard git tooling, no extra utility required. If the remote repository goes away for some reason, you'll have a full clone of the repository which will probably hold every version you care about. You can push it up somewhere, update the URL in .gitmodules, and new clones will work flawlessly, even when you check out historical versions which have a different URL in that version's .gitmodules. Overall, go's clean vendoring and general 'import' approach leads to git submodules being a perfect fit. Everything else is now legacy. 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
