Re: RFC/RFH submodule handling in big setups

From: Finn Arne Gangstad <finnag@pvv.org>
Date: Jan 7, 2008, 21:07 UTC
Message-ID: <20080107210735.GC19728@pvv.org>
In-Reply-To: <320075ff0801071208u1900bf76q2f0dc9cb0dc4318b@mail.gmail.com>

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.

Show 21 quoted lines

> 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