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
Moritz Angermann 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
Ömer Sinan Ağacan writes:
>> 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
Ömer Sinan Ağacan writes:
> while making the case of contributing patches with submodule changes more
> difficult
>
> I don't understand this, can you give an example of what absolute paths make
> harder?
>
> Looking at the wiki pages and scripts we need to make relative paths work for
>
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
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
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
You can specify `[skip ci]` in the commit message if you don't want to
run the pipeline. When you are done, just amend your commit with the
finalised note.
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
> 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
while making the case of contributing patches with submodule changes more
difficult
I don't understand this, can you give an example of what absolute paths make
harder?
Looking at the wiki pages and scripts we need to make relative paths work for
everyone, I think it's clear that absolute
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
Can’t we have absolute submodule paths? Wouldn’t that elevate the issue?
When we all had branches on ghc/ghc this
was not an issue.
Sent from my iPhone
> On 8 Jan 2019, at 5:24 AM, Ben Gamari wrote:
>
> Simon Peyton Jones via ghc-devs writes:
>
>> Would it be worth describing this workflow
Simon Peyton Jones via ghc-devs writes:
> Would it be worth describing this workflow explicitly in our "How to
> use GitLab for GHC development" page?
>
Yes, indeed it would. I have asked David, who is currently looking at
revising our contributor documentation, to do so.
Cheers,
- Ben
Would it be worth describing this workflow explicitly in our "How to use GitLab
for GHC development" page?
S
| -Original Message-
| From: ghc-devs On Behalf Of Ben Gamari
| Sent: 07 January 2019 15:33
| To: Moritz Angermann ; ghc-devs
| Subject: Re: GitLab forks and
Moritz Angermann 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
Hi *,
so what do we do with submodules? If you point someone to a fork of ghc, say:
gitlab.haskell.org/foo/ghc
and they try to check it out, they will run into issues because foo didn't
clone all the
submodules. So how is one supposed to clone a forked ghc repository?
Cheers,
Moritz
16 matches
Mail list logo
