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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
