Subject: Re: [PATCH v2 0/3] Teach fetch and pull to recursively fetch submodules too

From: Chris Packham <[email-masked]>
Date: Wed, 13 Oct 2010 18:01:04 -0700

On 13/10/10 13:06, Jens Lehmann wrote:
> 
> For *your* use case it might not be correct, but for others it may very
> well be.
> 
> We need to get more user stories like that to get an overview about what
> config options are useful and what might be reasonable defaults for them.
> And then we can decide what set of options and defaults to choose.

We'll if you want it here's an example of how we use submodules at $dayjob.

Most developers initially clone the project repo and run git submodule
update --init (or git submodule init && git submodule update if their
git version is too old).  This could be replaced by git clone
--recursive, or just git clone if we there was a config for enabling
recursive cloning by default.

A few newbies have been confused by the fact that they run git clone but
don't actually end up with any code (in our case the superprojects are
just containers with no actual code themselves).

We have a continuous integration machine that does a git pull on all
submodules, a few automated tests and updates the superproject if the
tests pass. This would make use of git fetch/pull --recursive to grab
all the latest changes.

After the initial clone developers run git pull on the project. for
modules they aren't working on they run git submodule update <module>.
For modules they are working on they to rebase their working branch to
the SHA1 recorded in the superproject. I think this kind of thing has
already been discussed on the list, not sure that I've seen a solution
that would work for us. For now all of this is is wrapped in a script
for the developers.

Developers would probably want the fetch-if-super-gitlink-has-changed
behaviour. We also need to handle rebasing a submodule's checkedout
branch (if present) against the recorded submodule SHA1. This could
remain "our problem" as long as the worktree of these branches does not
get updated we can simply use the existing rebase logic we have today.

Hope that is a useful use-case.
--
- Chris