Would it be worth describing this workflow explicitly in our "How to use GitLab for GHC development" page?
S | -----Original Message----- | From: ghc-devs <[email protected]> On Behalf Of Ben Gamari | Sent: 07 January 2019 15:33 | To: Moritz Angermann <[email protected]>; ghc-devs <ghc- | [email protected]> | Subject: Re: GitLab forks and submodules | | Moritz Angermann <[email protected]> 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 _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
