Re: RFC/RFH submodule handling in big setups

From: Finn Arne Gangstad <finnag@pvv.org>
Date: Jan 7, 2008, 20:49 UTC
Message-ID: <20080107204922.GA19728@pvv.org>
In-Reply-To: <7vr6gtzaeq.fsf@gitster.siamese.dyndns.org>

On Mon, Jan 07, 2008 at 11:46:21AM -0800, Junio C Hamano wrote:

Show 23 quoted lines

> 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