WIP branches

[Sylvain Henry]

> What is the advantage of having ghc-wip instead of having all devs just have their own forks?

I am all for each dev having its own fork. The ghc-wip repo would be just for devs having an SVN workflow (i.e. several people working with commit rights on the same branch/fork). If no-one uses this workflow or if Gitlab allows fine tuning of permissions on user forks, we may omit the ghc-wip repo altogether.

Regards,
Sylvain

PS: you didn't send your answer to the list, only to me

On 05/02/2019 19:44, Richard Eisenberg wrote:
> I agree that movement in this direction would be good (though I don't feel the pain from the current mode -- it just seems suboptimal). What is the advantage of having ghc-wip instead of having all devs just have their own forks?
>
> Thanks,
> Richard
>
>> On Feb 5, 2019, at 11:36 AM, Sylvain Henry <sylvain at haskus.fr> wrote:
>>
>> Hi,
>>
>> Every time we fetch the main GHC repository, we get *a lot* of "wip/*" branches. That's a lot of noise, making the bash completion of "git checkout" pretty useless for instance:
>>
>>> git checkout <TAB>
>> zsh: do you wish to see all 945 possibilities (329 lines)?
>>
>> Unless I'm missing something, they seem to be used to:
>> 1) get the CI run on personal branches (e.g. wip/USER/whatever)
>> 2) share code between different people (SVN like)
>> 3) archival of not worth merging but still worth keeping code (cf https://ghc.haskell.org/trac/ghc/wiki/ActiveBranches)
>>
>> Now that we have switched to Gitlab, can we keep the main repository clean of those branches?
>> 1) The CI is run on user forks and on merge requests in Gitlab so we don't need this anymore
>> 2 and 3) Can we have a Gitlab project ("ghc-wip" or something) that isn't protected and dedicated to this? The main project could be protected globally instead of per-branch so that only Ben and Marge could create release branches, merge, etc. Devs using wip branches would only have to add "ghc-wip" as an additional remote repo.
>>
>> Any opinion on this?
>>
>> Thanks,
>> Sylvain
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs