+1 Allowing both options while keeping linear history looks good. Kind Regards, Chandan Khandelwal
On Fri, Mar 13, 2026 at 4:02 PM Jacopo Cappellato < [email protected]> wrote: > For your reference, this is the ticket: > > https://issues.apache.org/jira/browse/INFRA-27732 > > Jacopo > > > On Fri, Mar 13, 2026 at 11:26 AM Jacopo Cappellato < > [email protected]> wrote: > > > Thank you for your feedback. > > Since there are no objections and we have received enough positive > > feedback (9 contributors, including 7 PMC members), I will proceed with > > filing the ticket with Infra and will use this thread as a reference. > > > > Regards, > > Jacopo > > > > On Wed, Mar 11, 2026 at 4:17 PM Jacopo Cappellato < > > [email protected]> wrote: > > > >> Hi all, > >> > >> Currently, the GitHub branch protection rules for our repositories > >> (ofbiz-framework, ofbiz-plugins, ofbiz-site, ofbiz-tools) enforce a > >> linear history, which is a good practice that helps keep the commit > >> history clean and easy to follow. > >> > >> I would like to propose a small refinement to these settings: allowing > >> "Rebase and Merge" as an additional merge option for pull requests, > >> alongside the currently used "Squash and merge". > >> > >> With this configuration, we would still enforce the constraint of a > >> linear history, but committers reviewing pull requests would have the > >> flexibility to choose between two approaches: > >> * Squash and merge: combine all commits in the pull request into a > >> single commit. > >> * Rebase and Merge: rebase the commits from the pull request and add > >> them individually to the main branch. > >> > >> The idea is that the choice would depend on the quality of the commit > >> messages in the pull request: > >> > >> * If the commits already contain clear, well-structured messages that > >> comply with the OFBiz guidelines, the committer could use Rebase and > >> Merge to preserve them. > >> * If the commit messages are not compliant with our guidelines or are > >> not particularly useful, the committer could use Squash and merge and > >> provide a new commit message that follows our conventions. > >> > >> This approach would allow us to maintain a linear and readable history > >> while also preserving high-quality commit histories when they are > >> provided. > >> > >> Please share your thoughts on this proposal. > >> > >> Best regards, > >> Jacopo > >> > > >
