Require Linear History Only for New Commits in Rulesets

[m-skolnick]

Select Topic Area

Bug

Body

Issue: Rulesets "Require Linear History" checks previous commits as well as new commits. Require Linear History in branch protections only required that new commits were linear (ie.. not merge commits).

This is a change in behavior we ran into when transitioning from branch protections to rulesets. This issue was brought up in the Repository Rules GA request for feedback here: https://github.com/orgs/community/discussions/61107#discussioncomment-6671872, but it was not addressed.

Actual behavior: Rulesets "require linear history" checks old commits as well as new commits when searching for merge commits
Expected behavior: Rulesets "require linear history" only blocks new merge commits from being pushed

Why this is a problem: We have multiple repos with extensive histories where there were merge commits made years ago. We want to now turn on "require linear history" but we are unable to because previous merge commits are being flagged in the ruleset and now every push to the repository is blocked. It looks like we only have two options: 1) Keep using branch protections to require linear history. 2) Rewrite our entire git history to remove all merge commits

[laurentkempe]

We are facing exactly the same issue, one year later!

[martinskuta]

We just migrated from branch protection rules and it happened to us even when creating a new "empty" branch from master. This rule is unusable as is for existing repos that have merge commits.

[ianbotsf]

My projects are in the same state as the commenters above: older monorepo that has some historical merge commits, enabled linear history requirement, now I can't create new branches from main. If there's no feature to require linear history only for new commits then what's the recommended strategy for maintainers to prevent new merge commits?

[DelusionalLogic]

I'm having a problem that looks a little like this. We're using Rulesets to require a tracking number in each commit, but tools (dependabot) are allowed to bypass that rule. The problem then is that when we have a commit that wants to rebase onto a branch that includes one of these tool generated commits the ruleset applies as through we created the commit, and blocks the push. This doesn't match the expectations of the user since they didn't create the "bad" commit.

It would be really nice if rulesets could somehow only validate new commits.

[zakkallen66]

Have you experienced similar challenges when transitioning from branch protections to rulesets?