Sounds like a good idea to start with disallowing --force for now, given there is --force-with-lease for emergencies. The unfortunate bit is perhaps that this opens up a way to modify history without noticing (which is what I've used it for too).
Cheers, Stefan On 23.01.18, 14:59, "Jason Bailey" <jason.bai...@sas.com> wrote: >The methodology with GIT is usually around never committing anything >directly to master, rather branch and merge. Internally I have our github >projects set up to prevent force pushes to master and to allow it on >branches so that the developer working on that branch has the option of >fixing things if there is an oops > >I haven't seen the -force-with-lease before so I can't say how well it >works, but that has definitely jumped to the top of my "commands to now >use" > >-----Original Message----- >From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] >Sent: Tuesday, January 23, 2018 8:49 AM >To: dev <dev@sling.apache.org> >Subject: Re: Git force push > >EXTERNAL > >On Tue, Jan 23, 2018 at 2:33 PM, Stefan Seifert <sseif...@pro-vision.de> >wrote: >> i would also vote for *not* allowing push --force.. > >+1, my understanding is that one can destroy history with that...which >we don't want. > >I have never used --force-with-lease so far but according to [1] it only >allows you to force-push if no-one else has pushed changes up to the >remote in the interim. > >If that's correct (does anyone have experience with it?) I'd be in favor >of allowing --force-with-lease but not --force. With our many >repositories we often have a single committer working on a given >repository for some time, in which case --force-with-lease could help, >apparently. > >-Bertrand > >[1] https://developer.atlassian.com/blog/2015/04/force-with-lease/
