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.
Right, this is a significant advantage of keeping WIP branches in the ghc repo. I agree that we should clear out some of the older, non-archival wip/ branches. One unfortunate side-effect of keeping WIP work in forks is that GitLab will not show the user that the branch has a corresponding MR when viewing its commit list. For instance if you look at [1] (a branch in the primary GHC repository associated with !298) GitLab will note the fact that the branch has an MR open with the "View open merge request" button on the top right of the page. However if we look at [2] (in osa1's fork, associated with !299) we see no such indication. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/commits/wip/nonmoving-gc