Re: git submodules and commit

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Jul 16, 2008, 11:35 UTC
Message-ID: <487DDCFC.9020007@viscovery.net>
In-Reply-To: <320075ff0807160402s7429291ela288b42d99c1ec53@mail.gmail.com>

Nigel Magnay schrieb:

Show 27 quoted lines

> On Wed, Jul 16, 2008 at 11:47 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> Nigel Magnay schrieb:
>>> For me, in some really high proportion of cases, I think I want 'git
>>> commit' to mean 'commit to any child repositories, any sibling
>>> repositories, and any parent repositories (updating the submodule sha1
>>> as appropriate). In other words, 'pretend like the whole thing is one
>>> big repo'.
>> And I think that this is the problem: If this way of commiting your
>> changes is *required* in the *majority* of cases, then you are IMO outside
>> the intended use-case of submodules. You are better served by really
>> making this one big repo.
>>
> 
> Hm - then my contention is that the scope of submodules needs to be
> expanded (or something needs to be built on top).
> 
> One-big-repo doesn't fly - > 75% of the code volume (the 'other'
> modules) are shared between multiple projects. In SVN these are just
> svn:externals (which has it's own imperfections).
> 
> I think it's a common usecase. You have 'shared' modules and
> 'project-specific' modules[*]. The 'shared' modules you hope don't
> change very much, but they are part of the overall project
> configuration - it's really nice that you can branch so easily in git,
> then get the module owner to merge those changes into the next release
> at their leisure. The superproject then represents the correct
> configuration of submodule trees to make a valid build.

Ah, is this your actual scenario? Just to make sure we are talking about the same thing:

- You own superproject P.
- $Maintainer owns submodule S.
- You use S in P.
- You make changes to S that you would like $Maintainer to include in the
next release.
x You use in P your changes to S while $Maintainer has not yet released a
new version of S with your changes.
- Finally your changes arrive via the new release of S.

That *is* the intended use-case for submodules. But you have to play the game by the rules:

- $Maintainer defines the official states of S.

- You must never commit an unofficial state of S in P.

The critical step in above list I marked with x:

- During the period where only *you* have the new changes to S, you must
*not* commit your submodule state to P. Instead, you write P in such a way
that it can work with both the old version of S and the upcoming release
that will have your changes[*]. This way you make sure that your consumers
of P always have a working version regardless of which version of S they use.

- After you have received the new release of S from $Maintainer, you
commit the new state of S in P. And if you are nice to your consumers of
P, then you *do not* remove the workaround from P just yet, so that you
don't force them to upgrade S. You will remove it later only if it becomes
a maintainance burden.

[*] If it is not possible to make P work with old and new versions, then you have to work closely with the $Maintainer so that you never need commit an unofficial state of S into P.

-- Hannes