matthewtpickering at gmail.com
Wed Feb 6 22:09:23 UTC 2019
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.
On Tue, Feb 5, 2019 at 4:36 PM Sylvain Henry <sylvain at haskus.fr> wrote:
> 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
> 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?
> ghc-devs mailing list
> ghc-devs at haskell.org
More information about the ghc-devs