WIP branches

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

WIP branches

Sylvain Henry-2
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIP branches

Sylvain Henry-2
> 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 <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIP branches

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


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 <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIP branches

Matthew Pickering
In reply to this post by Sylvain Henry-2
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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: WIP branches

Ben Gamari-3
Matthew Pickering <[hidden email]> writes:

> 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: WIP branches

GHC - devs mailing list
| 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.

This is quite important (to me). On several occasions already I have asked myself "have I opened a MR for this wip/ branch, and if so which MR?".   There really should be a way to answer that question.

Simon

| -----Original Message-----
| From: ghc-devs <[hidden email]> On Behalf Of Ben Gamari
| Sent: 06 February 2019 22:34
| To: Matthew Pickering <[hidden email]>; Sylvain Henry
| <[hidden email]>
| Cc: ghc-devs <[hidden email]>
| Subject: Re: WIP branches
|
| Matthew Pickering <[hidden email]> writes:
|
| > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha
| skell.org%2Fghc%2Fghc%2Fcommits%2Fwip%2Fnonmoving-
| gc&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Caf97c2f84a6f49e53dac08d68c8
| 32cb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850892378883131&amp;s
| data=%2Fdke1u5PQ0U%2F9PMzZBHGkJdR2OZplq2JUGDj8u1YXi8%3D&amp;reserved=0
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs