RE: 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. 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 On Behalf Of Ben Gamari | Sent: 06 February 2019 22:34 | To: Matthew Pickering ; Sylvain Henry | | Cc: ghc-devs | Subject: Re: WIP branches | | Matthew Pickering 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&data=02%7C01%7Csimonpj%40microsoft.com%7Caf97c2f84a6f49e53dac08d68c8 | 32cb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636850892378883131&s | data=%2Fdke1u5PQ0U%2F9PMzZBHGkJdR2OZplq2JUGDj8u1YXi8%3D&reserved=0 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: WIP branches
Matthew Pickering 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 signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: WIP branches
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 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
> 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@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: WIP branches
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 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 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
> >> 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@haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: WIP branches
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 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
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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
WIP branches
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
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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Non-wip/* branches
Joachim Breitner writes: > Hi, > >> facundominguez added a comment. >> >> @nomeata please, could you remove the branches fd/fix-travis and >> fd/fix-travis2? Some server hook is preventing me from doing so. > > turns out I cannot do that either (which I knew). From experience, I > know that I can create, force-push and delete branches of the form > wip/*, but can only create and fast-forward-push to branches that are > not of this form. > > This is mostly sensible, but it means that I cannot undo an accidental > branch creation outside the wip/* branch. > > Ben, can you delete the two mentioned branches? > Sure, but I need to run out at the moment so it will take a few hours. Cheers, - Ben > And more general, would it make sense to prevent common footfolk like > me form creating branches outside the wip/* namespace? This ensures > that I can always clean up a mess I make. I can still ask some of the > super admins, like you, should I for some reason require a branch > outside the wip/* namespace. > This sounds like a reasonable proposal to me. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Non-wip/* branches
Hi, > facundominguez added a comment. > > @nomeata please, could you remove the branches fd/fix-travis and > fd/fix-travis2? Some server hook is preventing me from doing so. turns out I cannot do that either (which I knew). From experience, I know that I can create, force-push and delete branches of the form wip/*, but can only create and fast-forward-push to branches that are not of this form. This is mostly sensible, but it means that I cannot undo an accidental branch creation outside the wip/* branch. Ben, can you delete the two mentioned branches? And more general, would it make sense to prevent common footfolk like me form creating branches outside the wip/* namespace? This ensures that I can always clean up a mess I make. I can still ask some of the super admins, like you, should I for some reason require a branch outside the wip/* namespace. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Commit messages for WIP branches (Was: Question about `validate` workflow)
On Nov 10, 2014, at 3:33 AM, Joachim Breitner wrote: > > We could experimenting with just sending those „branch wip/foo's head > updated“ mails, i.e. only one mail per push, listing the git commit > titles. That would greatly reduce the traffic, while still giving some > indication of action. I like this idea, as it still allows those who want to watch something closely to do so. Thanks, Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Commit messages for WIP branches (Was: Question about `validate` workflow)
Hi, Am Sonntag, den 09.11.2014, 21:53 -0500 schrieb Richard Eisenberg: > > Am Samstag, den 08.11.2014, 22:33 -0500 schrieb Richard Eisenberg: > >> I've stopped validating locally, allowing Travis to do it for me. If > >> you use a `wip/...` branch and push to the main GHC repo, you can find > >> build reports at travis-ci.org/ghc/ghc. Or, I'm sure if you clue > >> Travis in, this can also work if you push to your own GitHub fork of > >> GHC. > > > > of course this spams ghc-commits quite a lot. > > Which brings me to ask: why send email to ghc-commits for `wip/*` > branch commits? I've personally gone back and forth between using the > main GHC repo for my WIP because of precisely this issue. If there > were no emails generated, I would surely always use the GHC repo -- > it's easier for others to find my work, and tracking a branch in my > head is easier than a separate remote and a branch. As it is, I'm > always slightly embarrassed when I push to my `wip/rae` branch, > causing other people to get emails about my internal GHC meanderings. > But, I'm using GHC's repo now for better integration with Phab, for > when Harbormaster pulls base commits. > > So, I propose: Do not send commit emails for commits to `wip/*` > branches. > > What do we think? of course it is nice to know what others are working on, and someone interested in your particular thing might have a look. But especially due to rebasing the current commit message setup does not work for wip branches. We could experimenting with just sending those „branch wip/foo's head updated“ mails, i.e. only one mail per push, listing the git commit titles. That would greatly reduce the traffic, while still giving some indication of action. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Commit messages for WIP branches (Was: Question about `validate` workflow)
On Nov 9, 2014, at 2:42 PM, Joachim Breitner wrote: > Am Samstag, den 08.11.2014, 22:33 -0500 schrieb Richard Eisenberg: >> I've stopped validating locally, allowing Travis to do it for me. If >> you use a `wip/...` branch and push to the main GHC repo, you can find >> build reports at travis-ci.org/ghc/ghc. Or, I'm sure if you clue >> Travis in, this can also work if you push to your own GitHub fork of >> GHC. > > of course this spams ghc-commits quite a lot. Which brings me to ask: why send email to ghc-commits for `wip/*` branch commits? I've personally gone back and forth between using the main GHC repo for my WIP because of precisely this issue. If there were no emails generated, I would surely always use the GHC repo -- it's easier for others to find my work, and tracking a branch in my head is easier than a separate remote and a branch. As it is, I'm always slightly embarrassed when I push to my `wip/rae` branch, causing other people to get emails about my internal GHC meanderings. But, I'm using GHC's repo now for better integration with Phab, for when Harbormaster pulls base commits. So, I propose: Do not send commit emails for commits to `wip/*` branches. What do we think? Thanks, Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
