Re: Master ahead of staging

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Sun, Feb 16, 2020 at 5:23 PM David Kastrup <address@hidden> wrote:
>
>> Han-Wen Nienhuys <address@hidden> 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".