3 ms·

> Just Git submodules and you're done. It would be a disaster if popular Go projects started using submodules, and consequently required users and contributors

• davecheney 12y ago
  gb doesn't mandate any particular DVCS or DVCS strategy -- I understand it's a deeply personal issue for most. People are smart, if they like the tool, they'll figure out how to integrate it into whatever DVCS they use.
• ansible 12y ago
  I prefer subtrees to submodules. Not that subtrees are a cakewalk, in fact I wrote up a tutorial using them. [1] The main issue with submodules (for me anyway) is that it seems to be all too easy to revert a change in a submodule if you aren't careful. It is not very people-friendly because you're just looking at hashes, and it isn't clear which one is newer and which is older. [1] https://github.com/jamesgraves/example-go-app https://github.com/jamesgraves/example-go-app
• DannoHung 12y ago
  Submodules should be the right solution. Subtrees are weird as hell even if they require less interaction. I wonder if anyone in the git team has considered doing any updates on the porcelain for them. edit: BTW, even though syncs may be separate (and let's be honest, they should be really infrequent). You can do the update/init thing in one command: git submodule update --init --recursive