how to checkout proper submodules
Geoffrey Mainland
mainland at apeiron.net
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.
>>
http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/
>>
>> 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 darcs.haskell.org 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.
Geoff
>> 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