WIP branches

[Matthew Pickering]

Making `ghc-wip` sounds like a reasonable idea to me.

I have found that people pushing to the `wip/` branches makes things
much smoother so far as it means that I can rebase/finish/amend other
people's patches and just push to the same branch without having to
ask people to do annoying rebases etc.

Matt

On Tue, Feb 5, 2019 at 4:36 PM 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