Re: RFC/RFH submodule handling in big setups

[Finn Arne Gangstad <finnag@pvv.org>]

On Mon, Jan 07, 2008 at 11:46:21AM -0800, Junio C Hamano wrote:
> Finn Arne Gangstad <finnag@pvv.org> writes:
> 
> > We're trying to get git to work well with our vision of submodules,
> > and have to figure out how to make submodule fetching and pushing work
> > in a smooth way.
> >
> > This is our situation (simplified):
> >
> >           [product1]          [product2]  ...         (supermodules)
> >            /      \             /     \
> >     ... [foo]  [os-abstraction-lib] [log-merger] ...  (submodules)
> >
> > [...]
> 
> The phrase "without interfering with anyone else" feels somewhat
> wrong and I sense there is something missing in the description
> of the workflow.  When a developer pushes a change to somewhere
> else, it must be because the change needs to be shared with
> _somebody else_ (but not necessarily with _everybody_).
> 
> Without knowing exactly what the desired workflow is, I'd hazard
> a guess and would recommend something else, which is  hopefully
> a more useful way.

I'll try to explain a bit better, in different ways:

Way 1: Think of product2 as a big repository

I want to use git as if product2 was a single repository containing
all its submodules as directories.

I want to be able to send email patches agains product2 that affect
any number of the submodules. I want to apply these in any order, and
to let them live as topic branches in product2.

Way 2: Changes to several submodules must be "globally atomic"

If I change submodule 1 and submodule 2, I want to be able to commit
both those changes as one atomic change in the supermodule - in a
topic branch. When merging that topic branch in the supermodule, both
changes in the submodules are merged. But NOT BEFORE. The submodules
cannot be pre-merged (hence the need to push them "somewhere")

Way 3: The submodules are not released on their own

Only the products are released, each product has different release
criteria, code freezes, whatever. Syncing of submodules between
products happens rarely (a few times a year maybe). Modifications to
submodules must fit each product's release criteria.

There is usually no one who is responsible for each submodule, they
live their life as part of the supermodule. Anyone can modify a
submodule, but each product has a maintainer who decides what
modifications to the submodules are allowed in that product.


Does this make things clearer in any way?

- Finn Arne