Han-Wen Nienhuys <[email protected]> writes: > On Sun, Feb 16, 2020 at 5:23 PM David Kastrup <[email protected]> wrote: > >> Han-Wen Nienhuys <[email protected]> writes: >> >> > sorry, my mistake (another reason to move to different tooling.) >> >> I very strongly disagree. We don't want to move to a tooling where >> material that is untested in its context gets pushed to the resource >> > > You don't understand what I'm trying to say. > > If there is a policy that nobody pushes directly to master, the normal > course of action is to enforce that policy using tooling. Both GitLab > and GitHub offer "protected branches", see eg. > https://docs.gitlab.com/ee/user/project/protected_branches.html. Gerrit > offers per-branch permissions.
Ok. Strictly speaking that's not as much a matter of the tooling but of the system administration (part of which is done by tools on GitLab/GitHub). I have some sketch of a repository hook implementing our policy (master can only ff, staging _can_ be force-pushed, neither can be deleted, dev/name is free for name). But installing that would have meant extra work for the Savannah sysadmins. So in the end I decided not to bother. The solution would likely have been a better match to our current workflow than what GitLab can offer, but of course a partial solution beats an unimplemented solution. > It's not that hard to make it a habit to never push to master but >> instead to staging > > > it's pretty easy to push to master accidentally, because my shell > history is full of "git push origin HEAD:master" commands. I think a push command has enough of an effect that typing it in manually is not really much of a chore. If not fully sure, preceded by a push -n command. I don't think I ever referred to push commands by history. The most I do is use command line editing for the two-push job of resetting staging: git push origin :refs/heads/staging git push origin origin:refs/heads/staging (for example) in order to be sure that the branch I recreate is the same I removed. So after all that: more fine-grained manners of implementing policy without having to manually engage sysadmins certainly would be a boon. Not having the "I need to bother someone, possibly multiple times" threshold helps. -- David Kastrup My replies have a tendency to cause friction. To help mitigating damage, feel free to forward problematic posts to me adding a subject like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
