GitLab forks and submodules
ben at smart-cactus.org
Thu Jan 10 17:23:09 UTC 2019
Moritz Angermann <moritz.angermann at gmail.com> writes:
> Alright let me add some example that is really painful with submodules.
> Say I have a custom ghc fork angerman/ghc, because I really don't want
> to overload CI with all my stupidity and I *know* I'd forget to mark
> every commit with [skip ci] or something.
> Now I need to modify a bunch of submodules as well, say
> - libraries/bytestring
> - libraires/unix
> And next I want to have someone else collaborate on this with me, either
> for testing or contributing or what not.
> So I'm going to give them the following commands to run:
> git clone --recursive https://gitlab.haskell.org/ghc/ghc
> (cd ghc && git remote add angerman https://gitlab.haskell.org/angerman/ghc)
> (cd ghc && git fetch --all)
> (cd ghc/libraries/bytestring && git remote add angerman https://github.com/angerman/bytestring && git fetch --all)
> (cd ghc/libraries/unix && git remote add angerman https://github.com/angerman/unix && git fetch --all)
> (cd ghc && git checkout angerman/awesome/sauce)
> (cd ghc && git submodule update --init --recursive)
If you pushed your bytestring and unix changes to your gitlab account
then this wouldn't be necessary. The fact that we use relative paths
would actually work to your advantage.
My current thinking is that the fix-submodules script run by CI should
do the following for each submodule:
* If the branch has changed the submodule then do nothing (leaving the
submodule URL as relative; this ensures that a user can push their
submodule changes to their fork of the submodule on GitLab and things
will "just work"
* If the branch has not changed then rewrite the submodule URL to point
to gitlab.haskell.org/ghc/packages/.... This ensures that CI will work
for contributors making non-submodule changes in their GHC forks.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 487 bytes
Desc: not available
More information about the ghc-devs