GitLab forks and submodules

[Ömer Sinan Ağacan]

Sorry for reviving this thread, but this is causing so much trouble for me. I
want a fresh clone of a GHC fork. If I clone the fork it doesn't work for
reasons mentioned in this thread, however I just realized that it doesn't work
even if I fork gitlab/ghc/ghc and then add the fork as a new remote. Here's what
I do:

- Clone gitlab/ghc/ghc ("origin")
- Add gitlab/fork/ghc ("fork", the fork I want to build)
- git fetch --all
- git checkout fork/branch
- git submodule update --init

For whatever reason git tries to fetch submodules from "fork" instead of
"origin", and I couldn't find any way to tell git to use "origin" for submodule
instead. `git submodule sync` does not fix it. I also tried pulling submodules
before switching to the fork's branch, thinking that maybe if I initialize
submodules with the correct remote when I switch branches it'd fetch them from
there. The only way I could make this work is by replacing all relative URLs
with absolute URLs with this

    :%s/\.\./https:\/\/gitlab.haskell.org\/ghc/g

The argument for relative submodules doesn't make sense to me. Is updating a
submodule remote so hard that we want to make it easy at the cost of making lots
of other tasks so much harder? To me it makes sense that if you want to work on
a submodule you need to update its remote to your fork.

Ömer

Ben Gamari <ben at smart-cactus.org>, 10 Oca 2019 Per, 20:23 tarihinde şunu yazdı:
>
> 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.
>
> Cheers,
>
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs