Re: organizing multiple repositories with dependencies

In message <nngbomh3uz0.fsf@transit.us.cray.com>, dag@cray.com writes:

    > I agree and am willing to provide information about submodule use cases,
    > advantages and problems, but I'm not a user of subtree so I can't really
    > comment on it. Now that subtree is in git core, what about putting such
    > a comparison under Documentation/subproject-support.txt?

    That would be great.  Do you want to start work on that?  I can
    contribute some text about git-subtree.

I have a document I created for gitslave which I have cleaned up a bit and might be the start of such comparison.

---------------------------------------------------------------------- git-submodules is the legacy solution for putting repositories inside of other repositories. With git submodules, the submodule is checked out to a semi-fixed commit, typically on a detached HEAD. To make a change to the subproject, you need to check the submodule repository out onto the correct branch, make the desired change (possibly involving pull), commit, and then go into the superproject and commit the commit (or at least record the new location of the submodule). It was designed for third party projects which you typically do not doing active development on. Many/most git commands performed on the superproject will not recurse down into the submodules. submodules give you a tight mapping between subproject commits and superproject commits (you always know which commit a subproject was in for any given superproject commit). git-submodules is considered difficult to use for less experienced git developers who need to modify the subproject.

Another option is to stick everything in one giant repository, typically by using git-subtree. This might make your repository large and you have to manually run git-subtree commands to export your changes back out to the individual non-aggregated repositories. All git commands run as normal, though when examining pre-subtree history, you can see the individual lines of development on different branches.

gitslave creates a federation of git repositories—a superproject repository and a number of slave repositories—all of which may be concurrently developed on and on which all desired git operations will touch. In a typical use case, you would branch all repositories (to the same branch name) at the same time, and checkout or tag or get of the status of all repositories at the same time. For essentially any git command, you simply replace "git" with "gits" to get the specified git command to run on all repositories. Of course, some commands do not necessarily make a great deal of sense to run over all git repositories (eg. `git add filename`), but you are allowed to run any normal git command on any of the repositories at any time. gitslave provides a loose binding so that it is not necessarily completely clear which revision one repositories was at when a commit was made in a different repository, except after tag operations.

Another options include repo from Google, used with Android. Repo seems to work much like gitslave from a high level perspective, but there isn't a lot of documentation on using it for other projects.

Still another option is kitenet's mr which supports multiple repository types (CVS, SVN, git, etc). It is absolutely the solution for multi-SCM projects, but since it works on the lowest common denominator you would lose much of the expressive power of git.

The final option is to just put git repositories inside of other repositories. However, you must be sure to add the subproject into the superproject's .gitignore to prevent `git add` from adding the subproject as a broken submodule commit (broken because no .gitmodules or git-config entry will exist for it). ----------------------------------------------------------------------

					-Seth Robertson