4 ms·

Sad to say so, but this really makes a lot of sense - and it's dead simple, something I really appreciate as a Gopher. Suddenly you're able to have full contro

Sad to say so, but this really makes a lot of sense - and it's dead simple, something I really appreciate as a Gopher. Suddenly you're able to have full control over a project, use private repos effortlessly (even with SSH protocol) and most importantly for me, not check in all the dependencies and their changes like with Godep, which just keeps up messing up the history although having nothing to do with the project. Just Git submodules and you're done.

sagichmal 12y ago
> 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 to play the submodule init/update/sync dance. Please, please -- prefer subtrees.
- 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
nulltype 12y ago
This seems weird to me. While it's true that I don't want dependencies to mess up my git diff, I can't say that a dependency change has "nothing to do with the project". A change in dependencies almost always means a change in the behavior of my project. I guess what you're saying is that submodules means that the diffs are better somehow, but I can't remember ever enjoying using submodules. This whole thing seems more like a git problem than anything else.

sagichmal 12y ago

> 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 to play the submodule init/update/sync dance. Please, please -- prefer subtrees.

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

nulltype 12y ago

This seems weird to me. While it's true that I don't want dependencies to mess up my git diff, I can't say that a dependency change has "nothing to do with the project". A change in dependencies almost always means a change in the behavior of my project. I guess what you're saying is that submodules means that the diffs are better somehow, but I can't remember ever enjoying using submodules. This whole thing seems more like a git problem than anything else.