在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" ç_ç

Answer 1

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)

Answer 2

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.