Hi everyone, I know there's a lot going on in CentOS right now, but I still wanted to share with you all the follow up on the GItLab AMA session on Branches, in case you wished to read about it. So below are some links to the original documents and chat logs from the IRC session, and the main body of this mail is the questions and answers pulled directly from the Q&A sheet that specifically relate to branches. * Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w * Chat log from session https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html * AMA Blog post https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346 * Here is this email in hackmd if you wish to view it there: https://hackmd.io/me-0oLN-Qtmff1qMX2S-DA?view ## Topic: Branches Force pushing - Protected Branches - Question: Fedora forbids force-push in the main projects but allows them in forks. Would this be feasible in GitLab in a way that people cannot revert? - Answer: This can be done with Protected branches, basically (https://docs.gitlab.com/ee/user/project/protected_branches.html#protected-branches) Archived branches - Protected Branches - Question: Fedora supports the concept of retired git `branch` (ie: archived) that no-one can commit. Does GitLab have an equivalent concept? (The retired status is not something project admins can change) - Answer: Yes this is possible with Protected Branches https://docs.gitlab.com/ee/user/project/protected_branches.html#protected-branches - Question: Extending to above question, the sla's or eol dates are coming from a 3rd party service, when a user pushes to git branch, it will check the eol in that service and rejects it if it is already eol'd. Is this possible in GitLab? - Answer: Instead of this we would probably use the Protected Branches in GitLab. We could leverage the APIs to mass configure the branches on eol dates. That would mean that for each git push we don’t need to look at a 3rd party service to know if we can push or not. - Question: It is not allowed for users to delete the branches, only certain people with certain access levels are allowed to perform this operation. Is this possible in GitLab? - Answer: Yes protected branches can be used here https://docs.gitlab.com/ee/user/project/protected_branches.html#protected-branches Push permissions - Question: In CentOS, members of a group (say: storage-sig) can push to any branch starting with c<int>-<sig-name>-* (so for example, they can push to : c8-storage-sig-v2.0 or c7-storage-sig), but they cannot push to any other branches, like: c8, c7 or any of the branches starting with c8-kernel-sig and so on. Would this be doable in GitLab? (in a way that project owner/maintainer cannot edit?) - Answer: A Custom Push Rule and server hook (pre-recieve Git hooks behind the scenes) could help with this. - Question: Can we set permissions at branch level? Esp can we set them with some regex matching? - Answer: permissions accept wildcards, but not regexes. Regex can be used with custom push rules. See https://docs.gitlab.com/ee/push_rules/push_rules.html and https://docs.gitlab.com/ee/user/project/protected_branches.html#configuring-protected-branches. Hiding branches - Question: Is it possible to hide these retired branches from the UI? Say, hide branch names with f30 or lower? - Answer: This is not possible currently - Question: Currently a user is not allowed to rewrite the history. Is it possible? It would be nice to allow only certain people to do so. Although we might not use this, but its good to have just in case if we ever need it. - Answer: by default, only the `master` branch is protected against force push and deletion. It’s possible to configure other branches to be protected and who has permission to override. https://docs.gitlab.com/ee/user/project/protected_branches.html#configuring-protected-branches Branch level orphaning - Question: Orphaning a package or repo? A maintainer (owner) of the package can decide to orphan a package, the maintainer should only be able to assign the package to the `orphan` user or any of the other maintainers of the package only. Is this possible to set this branch level as well? - Answer: Yes, in the sense that who is allowed to push or merge to a specific branch is controllable at the user or group level. This can be at the specific branch level or based on a wildcard match based on branch name. See configuring protected branches for more details. There is one more topic from the AMA session on Naming issues with `+` and I will include any other Q&A's from the sheet that have not been posted yet. This will be out next week. I hope you have been finding this concentrated topic email useful and informative. This has been an extremely different year for everyone & we as a team have found ourselves with very little time to give to this project since the initial announcement, but I hope to engage with the community much more directly in 2021 as I work through this GitLab project formally to make sure we are making the best choices for everyone, straight through from end user to sys-admin, and everyone in between. Have a lovely weekend everyone and thank you again for your engagement and patience! Kindest regards, Aoife -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford