Re: HEADS-UP: Git submodule conversion imminent

Herbert, all, I just pulled the new HEAD and have a question which I believe was not addressed so far. In my work on the GHC tree I never pulled the dph subrepo because the only thing it adds for me is extra build time (of course I pull it for my validation tree because I have no choice). Now it seems that getting rid of dph is not that simple. If I `rm -df libraries/dph` then it gets restored after `./sync-all pull`. Running `rm -df libraries/dph/*` seems to prevent that but I imagine there will be problems if the dph submodule actually gets modified and I try to pull the latest version. Moreover in both cases `git status` lists the submodule content as modified, which I see as noise. So is there a good way of removing dph from the source tree? The only solution I see is to remove library/dph from the build tree (I use the lndir trick). This means I have DPH in the source tree but not in the symlinked build tree, which is not perfect, but acceptable. Janek Dnia sobota, 28 czerwca 2014, Gabor Greif napisał:

On 6/28/14, Herbert Valerio Riedel wrote:

...

On 2014-06-28 at 14:19:15 +0200, Gabor Greif wrote:

...

Hmm, I guess this was the reason, when I did that, I got

...

fatal: Needed a single revision Unable to find current revision in submodule path 'libraries/parallel'

so the other submodules were not initialized.

What might be wrong with 'libraries/parallel' ?

Tbh, not sure, but if you know you have nothing important in libraries/parallel,

rm -rf libraries/parallel

and retry a 'git submodule update --init'

This is essentially the suggested course of action according to

http://www.gostai.com/downloads/urbi-sdk-2.0/doc/urbi-sdk.htmldir/faq.htm l#x22-10400014.1.4

and other results you may get if you google for that error

Great, that helped!

Cheers,

Gabor

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs