I don't think I have ever done a force push on purpose so I had to refresh my memory on what the implications were for such things.
I found a summary snippet at https://github.com/orgs/eclipse-csi/discussions/7 that clarified the risks in my mind so maybe that info is helpful for others? Force-pushing allows the commit history of a repository to be rewritten, > which can pose a security risk. It can obscure the tracking of changes, > making it difficult to maintain a clear audit trail and potentially hiding > unauthorized modifications. By disabling force-push on default branches, we > aim to: > > - Protect code integrity: ensuring that the commit history remains > consistent and tamper-proof. > > > - Enhance auditing capabilities: making it easier to track changes and > review the evolution of the codebase. > > > - Support team collaboration: preventing accidental overwrites or loss > of work, and encouraging best practices like pull requests and code > reviews. > > So in general, that seems like a reasonable thing to do. It would be better if that could somehow be made the default for the sling organization instead of having to change hundreds of .asf.yaml files. Also, we may need to think of the process to handle the exceptions to that rule if a force push is temporarily necessary for some special case. Regards, Eric On Wed, Apr 30, 2025 at 6:32 AM Konrad Windszus <k...@apache.org> wrote: > Hi, > It seems that a git force push on the main branch is not disabled by > default for the Apache repositories. > However I would strongly suggest to enforce this. > This seems to require a dedicated item within the .asf.yaml for each > repository ( > https://github.com/apache/infrastructure-asfyaml?tab=readme-ov-file#branch-protection > ): > > ... > github: > protected_branches: > master: {} > … > > This will not add any additional branch protection but just the basic > disable force push (IIUC). > WDYT about adding this to all our .asf.yaml’s? > Do we use the branch name “master” consistently as default branch for all > our repos? > > Thanks for your comments, > Konrad > >
