Pushing subtrees in a git repo

Question

I'm quite new to Git: I come from SVN and there I found really powerfull the :external feature. Here in Git I haven't find something similar:

submodules are perfect for adding project modules that are not always required. They must be initialized after the repo cloning and you can't include only a subdir of the original project.
subtrees are really good for adding libraries (they also allow subdir inclusion), but pushing them is a real pain.

So the scenario is this: I have a project, in which I want to include some libraries. I want the possibility to change all these libraries and pushing them in their own repos. Moreover some of this libraries are subdirs of bigger projects (for example if a project includes also demos or readme files, I won't include those dirs in my project).

How can I do that?

I've tried:

http://progit.org/book/ch6-7.html + http://posterous.timocracy.com/git-sub-tree-merging-back-to-the-subtree-for (merging only a subdir isn't allowed, or I can't just see it);
http://www.tipstank.com/2011/02/21/git-subtree-notes-and-workflows/ (same as above, do not handle subdir inclusion);
http://psionides.eu/2010/02/04/sharing-code-between-projects-with-git-subtree/ (can't see nothing about pushing);
http://h2ik.co/2011/03/having-fun-with-git-subtree/ (can't see nothing about pushing)

Well, if you've reached this point, thanks for your patience, now I'd like something else to try, because right now my conclusion is: "subtree pushing isn't allowed in Git" ç_ç

http://stackoverflow.com/questions/3131912/why-are-git-submodules-incompatible-with-svn-externals/3132221#3132221: git submodules and external are different indeed. But you can change a submodule content and push to its repo: http://stackoverflow.com/questions/1979167/git-submodule-update/1979194#1979194. Basically, my answer would be the same than http://stackoverflow.com/questions/9394286/planning-repository-layout-for-git-migration/9395375#9395375 — VonC, Feb 22 '12 at 13:08
ok, thanks...but (please do correct me if I'm wrong) with submodules I can't "include" only a specific submodule-directory?? I mean: my submodule has two directories: Demos and Source and I want to include _only_ the Source content in my parent project...hope it's understandable... — noliv-mov, Feb 23 '12 at 09:05
correct: a submodule is a git repo of its own: you should checkout everything. While sparse checkout are possible (http://stackoverflow.com/a/2467629/6309), they aren't recommended. Using symlink to link only what you want to see is better. — VonC, Feb 23 '12 at 09:09
perfect...one last "noob" question: for "Using symlink to link only..." you mean that I checkout my "submodule" in another project and then symlink it?? But in this case git would think I'm committing "single files" not related to a different project, right? Or is there a way to say "hey, they are of another project!" — noliv-mov, Feb 23 '12 at 09:27
I have made an answer to illustrate the solution I propose and address your last comment. — VonC, Feb 23 '12 at 09:48

score 3 · Accepted Answer · edited May 23 '17 at 12:20

Couple of remarks from the comments:

git submodules are different from svn external
any modification done to a submodule can be push to its own remote repo.
"Planning repository layout for git migration" illustrate that you cannot always use submodules directly as the directory structure wouldn't be exactly what you need.

So I recommend:

loading (git checkout) the parent repo and all its submodules
creating elsewhere the correct structure, with symlink to the submodules (or subdirectories of the submodules in order to achieve what you need.
go back periodically to the git ain parent repo in order to detect any changes (dones from the other directory structure created outside of Git) in order to commit and push all submodules modifs, and then commit and push the parent repo.

git checkout

parent repo
  +
  +--> main project
    +
    +-> mainDir1
    +-> mainDir2
  +--> lib1
    +
    +-> lib1Dir1
    +-> lib1Dir2
  +--> lib2
    +
    +-> lib2Dir1
    +-> lib2Dir2

And your own project directory structure (for instance)

  +--> main project (symlink to ../parent/main project)
    +
    +-> mainDir1
    +-> mainDir2
    +-> lib1Dir1    (symlink to ../parent/lib1/lib1Dir1)
    +-> lib1Dir2    (symlink to ../parent/lib1/lib1Dir2)
    +-> lib2Dir2    (symlink to ../parent/lib1/lib2Dir2)

(note there is no lib2Dir1 (for instance) because in your actual project you don't need it)

thanks, your answer is really a fantastic idea I've never thought about. But now I'm understanding it isn't what I'm looking for...I mean: with your solution if I want to clone the project I have to do the symlinks, so it's not the turnkey solution I'd like to provide. Yes, it is far more easy than my previous solution with subtrees, but now I'm going to think that this is a "lack" of Git, isn't it? BTW thanks a lot for your patience!! — noliv-mov, Feb 23 '12 at 13:05

score 1 · Answer 2 · answered Jun 05 '12 at 12:13

VonC's solution is neat, but it has a disadvantage: There is no good way of capturing a configuration of your project+libraries at a point in time.

If you need to set up your project again, you'll need to checkout your project + the libraries, but they may all be on different branches and commits to what you had before.

So, if you follow VonC's suggestion, maybe create tags in each of the repos at the point when you make a release of your project, so that you can at least check them out again at the same point.

Otherwise, always move forwards and never check out an older version.

Pushing subtrees in a git repo

2 Answers2

Linked