Re: GitLab forks and submodules

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) instead of git clone --recursive https://gitlab.haskell.org/angerman/ghc --branch awesome/sauce Of course that would require me to change the absolute paths for bytestring and unix in my repo. So maybe I only need 5 instead of 7 commands to remember to tell, and type, and ... Cheers, Moritz

On Jan 8, 2019, at 11:16 PM, Carter Schonwald wrote:

Depending on the patch, the ci feedback may be fundamental. Eg some of the native code gen hackery im doing impacts a whole bunch of configurations I can’t do locally.

We could also have a wip/no-ci prefix ?

Either way it’s certainlu true that we have finite resources and should endeavor to use them thoughtfully

On Tue, Jan 8, 2019 at 5:32 AM Matthew Pickering wrote: I agree with Omer that we shouldn't encourage people to push wip branches to ghc/ghc. It wastes resources and pollutes the repo with lots of branches that will invariably not be deleted.

I would rather we use absolute paths in the submodule file as I have spent far longer than I expected trying to get git to use the right submodule in the past when operating on forks.

Matt

On Tue, 8 Jan 2019, 10:09 Gabor Greif

Gabor

On 1/8/19, Ömer Sinan Ağacan wrote:

...

...

As I mention in the documentation, those with commits bits should feel free to push branches to ghc/ghc.

This is sometimes not ideal as it wastes GHC's CI resources. For example I make a lot of WIP commits to my work branches, and I don't want to keep CI machines busy for those.

Ömer

Ben Gamari , 8 Oca 2019 Sal, 04:53 tarihinde şunu yazdı:

...

Moritz Angermann writes:

...

Can’t we have absolute submodule paths? Wouldn’t that elevate the issue?

Perhaps; I mentioned this possibility in my earlier response. It's not clear which trade-off is better overall, however.

...

When we all had branches on ghc/ghc this was not an issue.

As I mention in the documentation, those with commits bits should feel free to push branches to ghc/ghc.

Cheers,

- Ben _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs