The solution I use to this branch overload is changing my fetch refspecs to list explicitly the branches I want. <div><br></div><div><a href="https://git-scm.com/book/en/v2/Git-Internals-The-Refspec">https://git-scm.com/book/en/v2/Git-Internals-The-Refspec</a></div><div><br></div><div>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. </div><div><br></div><div>Tamar<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 5, 2019, 19:15 Sylvain Henry <<a href="mailto:sylvain@haskus.fr">sylvain@haskus.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> What is the advantage of having ghc-wip instead of having all devs just have their own forks?<br>
<br>
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.<br>
<br>
Regards,<br>
Sylvain<br>
<br>
PS: you didn't send your answer to the list, only to me<br>
<br>
On 05/02/2019 19:44, Richard Eisenberg wrote:<br>
> 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?<br>
><br>
> Thanks,<br>
> Richard<br>
><br>
>> On Feb 5, 2019, at 11:36 AM, Sylvain Henry <<a href="mailto:sylvain@haskus.fr" target="_blank">sylvain@haskus.fr</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> 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:<br>
>><br>
>>> git checkout <TAB><br>
>> zsh: do you wish to see all 945 possibilities (329 lines)?<br>
>><br>
>> Unless I'm missing something, they seem to be used to:<br>
>> 1) get the CI run on personal branches (e.g. wip/USER/whatever)<br>
>> 2) share code between different people (SVN like)<br>
>> 3) archival of not worth merging but still worth keeping code (cf <a href="https://ghc.haskell.org/trac/ghc/wiki/ActiveBranches" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/ActiveBranches</a>)<br>
>><br>
>> Now that we have switched to Gitlab, can we keep the main repository clean of those branches?<br>
>> 1) The CI is run on user forks and on merge requests in Gitlab so we don't need this anymore<br>
>> 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.<br>
>><br>
>> Any opinion on this?<br>
>><br>
>> Thanks,<br>
>> Sylvain<br>
>><br>
>> _______________________________________________<br>
>> ghc-devs mailing list<br>
>> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>