In message <nngbomh3uz0.fsf@xxxxxxxxxxxxxxxxxxx>, dag@xxxxxxxx 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html