Would it be worth describing this workflow explicitly in our "How to use GitLab for GHC development" page? S | -----Original Message----- | From: ghc-devs <ghc-devs-bounces@haskell.org> On Behalf Of Ben Gamari | Sent: 07 January 2019 15:33 | To: Moritz Angermann <moritz.angermann@gmail.com>; ghc-devs <ghc- | devs@haskell.org> | Subject: Re: GitLab forks and submodules | | Moritz Angermann <moritz.angermann@gmail.com> writes: | | > Hi *, | > | > so what do we do with submodules? If you point someone to a fork of ghc, | say: | > | > gitlab.haskell.org/foo/ghc | > | Indeed submodules have been a constant thorn in our side. We encounter | this same issue during CI jobs on forks. To work around this we have a | script (.gitlab-ci/fix-submodules.py) which tweaks the submodule paths | to point to gitlab.haskell.org/ghc/ghc. Others are free to use this | script locally however it is surely a hack. | | I suppose we could just try changing the submodule upstream URLs to | absolute URLs. This would make the (arguably more common) case of | cloning and contributing without submodule changes easier, while making | the case of contributing patches with submodule changes more difficult. | | My usual solution is to just clone from ghc/ghc and then add a separate | remote for my fork. | | Cheers, | | - Ben