5 ms·

I like a lot of these things for sure. The only thing that I really wish they'd do that I've seen no sign they plan to is move git-subtree from contrib into the

I like a lot of these things for sure. The only thing that I really wish they'd do that I've seen no sign they plan to is move git-subtree from contrib into the main distribution. It's such a useful thing.

aktau 13y ago
I agree! Overall I truly prefer git subtree over submodules. I've noticed that most devs seem to have strong opinions one way or another. Perhaps git subtree just seems so good because submodules are so clunky. If only someone would invent a "best of both worlds".
- etherealG 13y ago
  Any chance you could outline the downside of subtree? I've always thought it was better in every way.
  - sqs 13y ago
    Submodule can be used when you want to nest a private repository inside of a public one. Only authorized users will be able to fetch from the submodule repository. This can be useful in some cases, such as storing private keys in an otherwise public project. Also, if you have a very large submodule repository, it won't inflate the size of the repository that contains it.
    - stormbrew 13y ago
      git-subtree can flatten the other tree into a single commit while preserving the ability to use all its other functionality, which is actually probably a space-saving measure compared to submodules when you consider that anyone who uses your repo probably needs to get the submodule anyway, and that means downloading that other giant repo in its entirety vs. downloading a flattened copy of it.
      - stingraycharles 13y ago
        So if I understand this correctly, it is more of a convenient way to copy (and update) another repository into another one, instead of being a reference to another repository. To respond to the comment about this being useful for private keys: if this is the case, does this also mean unauthorized users will not be able to checkout the submodule at all? Or will they just get a copy of the files (which would not make sense with private keys).
        Tyr42 13y ago
        When you git clone a repository with a submodule, before you call git submodule sync/update and all that jazz, you just have an empty directory where the submodule should be.
  - beagle3 13y ago
    Subtree operations modify commits (and trees). As a result, cryptographically signing or validating a subtree operation does not extend to an independent module, and vice versa. If you care about these things, it's a big deal.
    - stormbrew 13y ago
      If you use git-subtree in the mode that doesn't flatten the original tree it does not, afaik, modify any commits on either side. The original tree, as imported, and the tree being imported to, are both parents of the post-subtree tree with their original SHAs.
      - beagle3 13y ago
        Wasn't aware of that. That's kind of awesome. You seem to be very knowledgeable about subtree, so I'll ask a question you can hopefully answer: I have multiple repositories each having 100,000-500,000 files, all relating to the same project. The reason I broke them up to multiple projects is that the git index doesn't handle millions of files all that well (e.g. index gets rewritten on every modification). Would subtree help me here in any way? Of course, this is not a usual way to use git, and Facebook opted for switching to Mercurial when faced with a similar problem (though an order of magnitude or two larger, I'm sure). submodules work for me now, but they are very clunky -- but the reason I didn't even try switching was the crypto signing of commits, which is apparently not a problem. Would subtrees help me with the scale as well in any way?
        stormbrew 13y ago
        No, I don't think subtrees can really help you with this unfortunately. At least not directly. Using the flattened mode might help, but then you'd be back to your problem with signing them. The subtree merge commit does record the original SHA, so I suppose you could verify as a separate step if you needed to that that merge commit is indeed the result of a correctly signed SHA somehow. But I think for your use case you're probably stuck with submodules.
- 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
- ingy 13y ago
  You may want to take a look at https://github.com/ingydotnet/git-subrepo#readme https://github.com/ingydotnet/git-subrepo#readme (and join #git-commands on freenode).
  - aktau 13y ago
    Wow, from glancing at the description it sounds really good. I hope you guys can pull it off! Something like this would be almost as "freeing" to me as starting to use git in the first place was.
rip747 13y ago
how close is git-subtree to svn-externals? I've always had people complain about moving from svn to git because there wasn't a feature like svn-externals. git-submodules obviously didn't cut it.
- TheHippo 13y ago
  In my opinion it's way better then submodule or svn-externals. Basically it allows you to take an specific folder from your repository and push only this folder to an additional repository. This repository could be included into another repository which makes sharing code between repositories very easy while keeping history in each of them and the history for this special folder in an extra repository.
- stormbrew 13y ago
  It's kind of difficult to compare. I actually think of submodules as being much closer to svn externals in nature, just very poorly integrated (I'm not sure anyone on the git core team actually uses submodules, in things I've read as justification for its poor implementation from core team members it seems like they only added it as a checkbox feature). Subtrees are quite different from either. They make the imported repository literally a part of the commit graph of the parent tree through a subtree-merge-commit. It then does some extra work to help you bring in new changes or export new changes back. I think it's a better approach than either, but it's also not exactly the same thing, basically.

aktau 13y ago

I agree! Overall I truly prefer git subtree over submodules. I've noticed that most devs seem to have strong opinions one way or another. Perhaps git subtree just seems so good because submodules are so clunky. If only someone would invent a "best of both worlds".

etherealG 13y ago
Any chance you could outline the downside of subtree? I've always thought it was better in every way.
- sqs 13y ago
  Submodule can be used when you want to nest a private repository inside of a public one. Only authorized users will be able to fetch from the submodule repository. This can be useful in some cases, such as storing private keys in an otherwise public project. Also, if you have a very large submodule repository, it won't inflate the size of the repository that contains it.
  - stormbrew 13y ago
    git-subtree can flatten the other tree into a single commit while preserving the ability to use all its other functionality, which is actually probably a space-saving measure compared to submodules when you consider that anyone who uses your repo probably needs to get the submodule anyway, and that means downloading that other giant repo in its entirety vs. downloading a flattened copy of it.
    - stingraycharles 13y ago
      So if I understand this correctly, it is more of a convenient way to copy (and update) another repository into another one, instead of being a reference to another repository. To respond to the comment about this being useful for private keys: if this is the case, does this also mean unauthorized users will not be able to checkout the submodule at all? Or will they just get a copy of the files (which would not make sense with private keys).
      - Tyr42 13y ago
        When you git clone a repository with a submodule, before you call git submodule sync/update and all that jazz, you just have an empty directory where the submodule should be.
- beagle3 13y ago
  Subtree operations modify commits (and trees). As a result, cryptographically signing or validating a subtree operation does not extend to an independent module, and vice versa. If you care about these things, it's a big deal.
  - stormbrew 13y ago
    If you use git-subtree in the mode that doesn't flatten the original tree it does not, afaik, modify any commits on either side. The original tree, as imported, and the tree being imported to, are both parents of the post-subtree tree with their original SHAs.
    - beagle3 13y ago
      Wasn't aware of that. That's kind of awesome. You seem to be very knowledgeable about subtree, so I'll ask a question you can hopefully answer: I have multiple repositories each having 100,000-500,000 files, all relating to the same project. The reason I broke them up to multiple projects is that the git index doesn't handle millions of files all that well (e.g. index gets rewritten on every modification). Would subtree help me here in any way? Of course, this is not a usual way to use git, and Facebook opted for switching to Mercurial when faced with a similar problem (though an order of magnitude or two larger, I'm sure). submodules work for me now, but they are very clunky -- but the reason I didn't even try switching was the crypto signing of commits, which is apparently not a problem. Would subtrees help me with the scale as well in any way?
      - stormbrew 13y ago
        No, I don't think subtrees can really help you with this unfortunately. At least not directly. Using the flattened mode might help, but then you'd be back to your problem with signing them. The subtree merge commit does record the original SHA, so I suppose you could verify as a separate step if you needed to that that merge commit is indeed the result of a correctly signed SHA somehow. But I think for your use case you're probably stuck with submodules.
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
ingy 13y ago
You may want to take a look at https://github.com/ingydotnet/git-subrepo#readme https://github.com/ingydotnet/git-subrepo#readme (and join #git-commands on freenode).
- aktau 13y ago
  Wow, from glancing at the description it sounds really good. I hope you guys can pull it off! Something like this would be almost as "freeing" to me as starting to use git in the first place was.

rip747 13y ago

how close is git-subtree to svn-externals? I've always had people complain about moving from svn to git because there wasn't a feature like svn-externals. git-submodules obviously didn't cut it.

TheHippo 13y ago
In my opinion it's way better then submodule or svn-externals. Basically it allows you to take an specific folder from your repository and push only this folder to an additional repository. This repository could be included into another repository which makes sharing code between repositories very easy while keeping history in each of them and the history for this special folder in an extra repository.
stormbrew 13y ago
It's kind of difficult to compare. I actually think of submodules as being much closer to svn externals in nature, just very poorly integrated (I'm not sure anyone on the git core team actually uses submodules, in things I've read as justification for its poor implementation from core team members it seems like they only added it as a checkbox feature). Subtrees are quite different from either. They make the imported repository literally a part of the commit graph of the parent tree through a subtree-merge-commit. It then does some extra work to help you bring in new changes or export new changes back. I think it's a better approach than either, but it's also not exactly the same thing, basically.