Hi, Any reason not to protect *all* branches from force push?
I see in my uima commits folder messages from [email protected], which say things like: This is an automated email from the ASF dual-hosted git repository. rec pushed a commit to branch 3.0.x in repository https://gitbox.apache.org/repos/asf/uima-uimafit.git ... and then details, including the message. So it appears that commits are generating messages to the commits list. What is the reason for your view on rebase or squash? What I vaguely understand is that if you have a git change process that branches, does work (possibly with many commits) and then eventually, does a merge of some kind with the base, that these things make the commit look like one thing (they loose the incremental history of what you were doing while working on the branch). I guess some people like the main branch to not have all the start/stop/change-your-mind/ set of little commits, in the branch, preserved in the main. Is your comment "please don't *force* ..." mean you advocate we allow all styles of pull request merging? Thanks for responding! -Marshall On 8/22/2019 3:53 PM, Richard Eckart de Castilho wrote: >> On 22. Aug 2019, at 20:53, Marshall Schor <[email protected]> wrote: >> >> Here are some I've found: >> >> 1) ban force push to some branches (e.g. master and master-v2 branches) > Any "main" branches should be protected from force commits. I think we should > be > protecting master and define some convention like that maintenance > branches always start with "maintenance/", e.g. "maintenance/2.10.x" > or something like that to avoid having to ask for protection of a new branch > after every feature release. > >> 2) setting commits mailing list to be the same as it is now (maybe the >> default?) > I don't remember anymore if they send commit notifications to the dev list by > default, > but doesn't hurt to ask. > >> 3) fixing pull requests to (a) disable "merge", and enable only "rebase and >> merge" or "squash and merge"? > Please don't force rebase or squash. > >> 4) setting JIRA integration so that a commit message with a Jira number gets >> linked in that Jira > I thought they (INFRA) do that by default... for uimaFIT, I didn't set any > options > as far as I remember. Maybe I should have...? > >> 5) require a Jenkins job to pass before a pull request is pushed to master / >> master-v2. > A Jenkins job to build pull requests should be set up, yes. And merges to the > protected branches should be prevented unless Jenkins is good. > > Cheers, > > -- Richard
