Re: RFC/RFH submodule handling in big setups

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

On Mon, Jan 07, 2008 at 08:08:38PM +0000, Nigel Magnay wrote:
> Do you currently use svn?

Currently we use CVS. It hurts a bit.

> This feels like the common technique of using svn:externals, where
> product1 has
> foo repo/foo/trunk
> os-abstraction-lib repo/os-abstraction-lib/trunk
> 
> product2 has
> os-abstraction-lib repo/os-abstraction-lib/trunk
> log-merger repos/log-merger/trunk
> 
> Where git (if I understand submodules correctly) can't do the above,
> because the links are to SHA1s rather than tags or names, so in svn
> terms it'd be something like
> os-abstraction-lib repo/os-abstraction-lib/trunk@xxx
> log-merger repos/log-merger/trunk@yyy
> 
> At first I thought the option (4) you suggest (Manually push all
> sub-modules to some new branch before pushing the  super-module) was
> going to be a pain - but actually I came to the conclusion it was
> actually better. In our svn world, commits to shared libraries (can)
> cause all hell to break loose - it'd actually be an advantage to have
> to promote changes into the supermodules (the products in our case).

With the way we envision using git, I don't think this is a
problem. Each supermodule decides what version of the shared library
it wants to use, and since git does not point to tags/branches in
submodules but to sha1s, there is nothing you can do to a submodule
that will cause any problems in a supermodule unless the supermodule
decides to use a new version.

I think we'd be perfectly happy to use detached HEADs in all
submodules, but there is no way to get that to work currently with
push and fetch, so I'm looking for some alternative.

- Finn Arne