5 ms·

>I've noticed that most devs seem to have strong opinions one way or another. I've personally noticed that most devs don't have an opinion either way since the

by bru 13y ago

>I've noticed that most devs seem to have strong opinions one way or another. I've personally noticed that most devs don't have an opinion either way since they don't use subtrees nor submodules. I don't know what subtrees offer but using submodules has been very pleasant once you know how they work. For example if you version control your .vim I think that adding submodules for extensions is way better than cloning them inside your .vim. I look forward to having the opportunity to use subtrees.

pmr_ 13y ago
I used to do this for my .emacs files and modules. It worked quite well, but in the end package.el made it unnecessary. Since then I came to the conclusion that git submodules are not a real substitute for a package manager.
- bostonvaulter2 13y ago
  And for vim vundle makes this unecessary. https://github.com/gmarik/Vundle.vim https://github.com/gmarik/Vundle.vim
stormbrew 13y ago
And then you try to bisect on a repository using submodules and you tear your goddamn hair out.
sanderjd 13y ago
Subtrees interact with history in a much more obvious, configurable, and automatic way. The most obvious win is never having to run `git submodule update`. The better control over history is the bigger, but less obvious win. Since you have some experience using submodules for your .vim, maybe try switching to subtrees and see what you think. I like the Atlassian blog post[0] about them for getting started. [0]: http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/ http://blogs.atlassian.com/2013/05/alternatives-to-git-submo...
- bronson 13y ago
  For me the the most obvious win is still being able to merge, move forward in time, move backward in time, rebase, etc. Everything that makes Git great. Once you have submodules in your repo, all that becomes heinous. PLUS everything you mentioned... Sure, if you don't use those features, then submodules would probably work fine. But then why not just use Dropbox?
  - sanderjd 13y ago
    Yep, I think a good way to put it is that subtrees are (or feel like) far more "first class" - you can do all the normal stuff with them.

by bru 13y ago

pmr_ 13y ago

I used to do this for my .emacs files and modules. It worked quite well, but in the end package.el made it unnecessary. Since then I came to the conclusion that git submodules are not a real substitute for a package manager.

bostonvaulter2 13y ago
And for vim vundle makes this unecessary. https://github.com/gmarik/Vundle.vim https://github.com/gmarik/Vundle.vim

stormbrew 13y ago

And then you try to bisect on a repository using submodules and you tear your goddamn hair out.

sanderjd 13y ago

Subtrees interact with history in a much more obvious, configurable, and automatic way. The most obvious win is never having to run `git submodule update`. The better control over history is the bigger, but less obvious win. Since you have some experience using submodules for your .vim, maybe try switching to subtrees and see what you think. I like the Atlassian blog post[0] about them for getting started. [0]: http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/ http://blogs.atlassian.com/2013/05/alternatives-to-git-submo...

bronson 13y ago
For me the the most obvious win is still being able to merge, move forward in time, move backward in time, rebase, etc. Everything that makes Git great. Once you have submodules in your repo, all that becomes heinous. PLUS everything you mentioned... Sure, if you don't use those features, then submodules would probably work fine. But then why not just use Dropbox?
- sanderjd 13y ago
  Yep, I think a good way to put it is that subtrees are (or feel like) far more "first class" - you can do all the normal stuff with them.