Idea:

In the context of Merge Queue, the current behaviour removes per-PR merge strategy choices (e.g., “squash on merge” vs “merge commit”) once the merge queue is enabled on a repository. Today, the queue controls the final merge strategy, so developers can no longer choose to squash their branch when merging.

The proposed feature is to restore a per-pull-request “squash” option that would apply before the PR enters the merge queue. Concretely:

On the PR level, a developer could still choose “Squash” (or an equivalent option) even when Merge Queue is enabled.

When the PR is added to the queue, the system would:

• First perform the squash (collapsing the branch into a single commit, with the usual squash-commit message behaviour).

• Then proceed with the queue’s configured merge strategy for the final integration into the target branch.

This keeps merge queue as the ultimate authority on how changes land on the main branch, but still lets individual contributors manage their own commit history in a way that’s already very common with “squash on merge”.

 

Use Case:

This is especially valuable for teams where:

• Some devs are used to squashing at merge time, and

• Others prefer merge commits, and

• The team wants to adopt Merge Queue without everyone having to abandon their existing workflows immediately.