block autosquash/fixup commits

[turadg]

What is the Problem Being Solved?

We've taken to using fixup! commits in PRs so the reviewer can see the revision to the commits but they get squashed before master. Sometimes the author forgets to squash before merging to master, so fixups end up in master branch and make it harder to see meaningful changes (in history and in git blame).

Description of the Design

Set up CI for master that prevents such commits. E.g. https://github.com/xt0rted/block-autosquash-commits-action

Security Considerations

Scaling Considerations

Test Plan

[mhofman]

Only a problem if we don't use mergify's rebase process.

I'd prefer to find a solution that handles these commits and automatically "does the right thing" with them.

[turadg]

Only a problem if we don't use mergify's rebase process.

Note that some of the fixup commits in master were while Mergify's rebase process was available. If you're proposing that we only ever allow merges to master using Mergify's rebase then, yes, we wouldn't need this. Barring that, fulfilling this issue is useful.

[mhofman]

To be more specific, squash "merging" also does not expose that issue. It's only a problem for the pure merge commit merging method, which is currently implicit for GH based merge queues, and explicit for the automerge:merge mergify based label process. It's only for these cases we should enforce a no fixup commit rule.

If we keep a GH merge queue process, I'd like to replicate the squash / rebase+fixup+merge methods. Hence the comment about not blocking but automatically handle these commits.

[mhofman]

Well this won't effectively be closed until we make the linear-history check required.

[mhofman]

linear-history is now a required check that should prevent these commits from mistakenly making it into master