how to checkout proper submodules

Geoffrey Mainland mainland at
Sat Jun 8 09:38:27 CEST 2013

On 06/06/2013 09:44 PM, Simon Marlow wrote:
> On 05/06/13 16:59, Ian Lynagh  wrote:
 >> On Tue, Jun 04, 2013 at 09:05:58PM -0500, Austin Seipp wrote:
 >>> I know we had this discussion sometime recently I think, but can
 >>> someone *please* explain why we are in this situation of half
 >>> submodules, half random-floating-git-repository-checkouts?
 >> Submodules are very handy for libraries that someone else maintains: We
 >> can make a local change to the library when we need something fixed,
 >> and then, when upstream has a fix too, we can jump straight to their fix
 >> without having to do any merging.
 >> However, submodules have various disadvantages, e.g.
 >> The main one for me is that it's fairly easy to lose local changes when
 >> using submodules. This is relatively unimportant for the libraries that
 >> someone else maintains, as we don't often make any local changes to
 >> lose. Even so, I've lost changes on a couple of occasions.
 > Drive-by-comment: 'sync-all new' doesn't work since we switched to
 > submodules.  If someone could fix that I'd be very grateful (or
 > alternatively tell me what workflow you use to figure out what patches
 > you have in your local repos that aren't upstream).
 > Another thing that annoys me about submodules is that I like to keep a
 > local mirror of the GHC repos on my computer.  When I clone from it,
 > the submodules all come from instead of my local
 > mirror. I know how to fix this by hand, but it's sync-all's job to get
 > this right (it does for the other repos).
 > Cheers,
 >     Simon

Yes, I have hit this problem too. It's the cause of many of the nightly
build failures at GHC HQ.

Does anyone know how to get git-submodule to use a mirror? There is the
--reference option to 'git submodule update', but I think it still needs
a network connection.


>> So the reason we entered  this state is that we didn't think the
 >> advantages outweighed the disadvantages for the other repositories.
 >> Thanks
 >> Ian

More information about the ghc-devs mailing list