Is anyone really using git super/subprojects?

Question

Is anyone using the new git super/subproject feature in real projects? How well does it work? For instance, I understand that if I push to a subproject I have to manually ca

Answer 1

If you mean submodules, then certainly.

The submodules don't and should not know everywhere they're used. For example, I have one submodule that is used in several projects that I know of (and quite possibly several that I don't).

Pushing to a submodule does not in any way affect the version of code used by the project containing the submodule, so I'm not sure what you'd want a hook to do anyway.

Answer 2

FWIW, we are trying to make the leap to git, and our project (bitweaver, a content management system) is a highly modular system, with nearly 160 repositories). A "build" generally contains two dozen or more sub-repositories. We used 'virtual modules' in CVS, and this worked fantastically for us, however CVS has it's own limitations for staging commits.

Git submodules have some severe limitations, and you should definitely evaluate mercurial's implementation as it is a certainly more friendly and flexible for external/modular projects (ie it supports other VCS systems, even HgGit).

Here are the biggest challenges:

1. Each submodule is hard linked to a particular commit when you "git submodule add" in the super-respository. This is by design, and sought as a benefit by git maintainers, so I would not expect it to change any time soon. This is painful in a system like ours where commit's are always happening in the submodules. You have to update the super project to keep up, or update your sub-repos to master after initial submodule update. (see supergit below for our solution).

2. You cannot easily commit and push to all the sub-repo's from the root. This is also very annoying, see supergit below.

3. Various gotchas that can be excruciating, especially things that "silently overwrite changes".

supergit

We've written a shell script call supergit that handles some of the painfulness. It does the clone, submodule init, update, and checkout master all in one fell swoop. It will also perform git commands to all directories in the super-repo individually (bulk git processing of sorts).

HTH, good luck.

Answer 3

By using submodule, you are defining in your Git workspace (meaning your "super-project" Git repository) a configuration.
By "configuration", I mean "the list of tags or SHA-1 node necessary to work in your workspace".
(and by work, I mean whatever "development effort" you are doing within your workspace: classic compilation, or patch, or merge, or deployment, or...).
That is the case when your are cloning a super-project and "git update" your submodules: you are checkouting the exact repos SHA1 which were previously committed in the super-project (recorded as gitlink in the index).

The other mode is when you are working on your super-project and on one or more submodules.
That means, for a given submodules, you have checked out a specific branch (you are no longer using a detached HEAD for the content of that submodules, but rather a pointer to the tip of a branch).
Then, "pushing a submodule" means updating a distant repository containing that sub-module (and only that one).

The actual trick in that last scenario (which could deserve a hook of you want one) is when you are pushing the super-project: you need to be sure to have pushed all your sub-modules first.

From the submodule tutorial:

Always publish the submodule change before publishing the change to the superproject that references it. If you forget to publish the submodule change, others won't be able to clone the repository (of the super-project)

Don't forget you can configure a submodule to follow a branch.