WIP branches

Phyx lonetiger at gmail.com
Tue Feb 5 19:32:44 UTC 2019


The solution I use to this branch overload is changing my fetch refspecs to
list explicitly the branches I want.

https://git-scm.com/book/en/v2/Git-Internals-The-Refspec

It's not ideal but it gets the job done. I wish git allowed you to exclude
branches instead, as I could just exclude /wip/* then.

Tamar

On Tue, Feb 5, 2019, 19:15 Sylvain Henry <sylvain at haskus.fr> wrote:

> > 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
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190205/25b40999/attachment.html>


More information about the ghc-devs mailing list