[petsc-dev] [petsc-users] new book introducing PETSc for PDEs

[Jed Brown]

Ed Bueler <elbueler at alaska.edu> writes:

> satish> Perhaps if some of us get this (create branch) access at
> https://github.com/bueler/p4pdes - the workflow is slightly
> satish> simplified [and a fork can be avoided which would require toggle of
> giturl as the MR progresses between
> satish> fork url and upstream url - and the commit-ids that change as the
> upstream MR progresses..]
>
> I appreciate the desire to avoid working in forks, so I went ahead and
> invited Barry, Jed, Satish as collaborators on p4pdes.  Please let me know
> if there are others to invite.

Thanks. I don't think this materially changes the workflow, but it does
mean PETSc's configure doesn't need to learn how to switch remotes in
packages it downloads, and .../packages/p4pdes.py can just name commits so
long as review in bueler/p4pdes just results in new commits rather than
editing/rebasing the branch.

> Indeed, I suppose my preferred workflow on p4pdes is for collaborators to
> create branches and do MRs.  It looks like actually restricting
> collaborators from pushing on master is not something I can do.  ("The
> ability to restrict branches is a type of branch protection that's
> available for public and private repositories owned by organizations in
> GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server.")
> Other forms of protecting master look like they add steps to my own (direct
> and minimal) workflow on master.

You should be able to click "Add rule" here

https://github.com/bueler/p4pdes/settings/branches