Support squash merges

[pitaj]

Currently, we rely on the PR author to squash their commits. This results in an extra review cycle.

But often, they'll just end up squashing their commits into a single commit. In those cases, that extra cycle could be avoided by performing a squash automatically.

This feature would enable @bors r+ squash to automatically squash all commits in the PR into a single commit with a message composed of the PR title and body. The squash would be performed before roll-up if applicable, or otherwise before merge.

[albertlarsan68]

It should force-push the PR branch with the squashed commit, in order to correctly mark the PR as merged.
I think it should error if not possible, mainly when the Allow Edits By Maintainers box is unchecked, if possible at all.

[pitaj]

I don't think that is very important, given most PRs aren't marked as merged as it is today. The solution to that is for GitHub to add a way to "Close as Merged".

I'd prefer just performing the squash on rust-lang-ci.

nvm

[Mark-Simulacrum]

I don't understand, all PRs are marked as merged today? I don't think we have problems there...

[pitaj]

Oh hmm for some reason I thought anything part of a rollup wasn't closed as merged. Not sure why I thought that.

Regardless, GitHub has the ability to squash-merge a PR with the API, so shouldn't it be possible to use that?

[Kobzol]

I haven't found a GitHub API that would allow me to squash without doing the actual merge, we need that for running tests before we merge the PR. The goal for this bot was to avoid local git operations, but maybe we will eventually have to give up on that.

FWIW it's still unclear how (and if) will this bot do merges (will PRs run on rust-lang or rust-lang-ci? will we use GH merge queues? etc.).

[pitaj]

I haven't found a GitHub API that would allow me to squash without doing the actual merge

It's a tad convoluted, but I think bors could open a new PR on rust-lang-ci and immediately squash merge it there.

[Kobzol]

It's a tad convoluted, but I think bors could open a new PR on rust-lang-ci and immediately squash merge it there.

If this was the only way, I would probably go the "offline git" route instead. The bot should be generic (=usable for any repository) and it would be quite annoying if it required another repository to perform one of its features.

[pitaj]

The bot should be generic (=usable for any repository) and it would be quite annoying if it required another repository to perform one of its features.

Yeah unfortunately it's not possible to open multiple PRs for the same branch.

@Mark-Simulacrum can you add "ability to apply merge_method (from Merge a pull request) to Merge a branch" to your agenda for discussion with GitHub?

[pitaj]

Actually there is an even more convoluted way to achieve this:

• create a copy of the branch
• create a new PR from the copy
• squash merge that PR

[Kobzol]

I think that creating a new (dummy) PR just for squashing is a no-go.

[tgross35]

I think maybe what could be better is a command like r+ needs-rebase which would auto-approve any future pushes as long as the content doesn’t change, the commit count is fewer, and there are no new merge commits. Bors could link to some docs indicating how to squash / reword well.

This way you sidestep figuring out how bors could do it, don’t need rereview, and hopefully wind up with a better commit message than the result of a squash. Auto squashed commit messages still wind up containing the small commit garbage messages, like

Add feature to do X

• format
• remove old code
• fixup

[mdeville]

Here's the strategy used by the now-archived bors-ng/bors-ng project.
FYI I used Copilot to document the following but the strategy seems to make sense and avoids creating dummy PRs.
Link to the code for those who prefer reading Elixir.
I will do my best attempt to replicate this behavior.

1. Prepare a temporary branch.

The batcher creates a temporary branch (stmp = "#{project.staging_branch}-squash-merge.tmp") based on the target branch's latest commit.

2. For each PR (patch) in the batch, in order:

For each patch, it retrieves:

• The list of commits for the PR.
• The PR’s head SHA (the commit to merge).
• The user info for the PR author.
• The user’s email (either public or from the first commit).

It then performs GitHub.merge_branch!:

• Merge the PR's head SHA into the temporary branch (stmp).
• Commit message includes [ci skip][skip ci][skip netlify] -bors-staging-tmp-<pr_xref>

This checks for conflicts and merges commits sequentially.

3. Squash each merge into a single commit.

For each merged PR the batcher creates a squash commit:

• Uses the tree of the merged commit and the previous HEAD as parent.
• Commit message is generated to summarize the PR (includes co-authors, body truncation, etc.).
• Committer is set to the PR author.

4. Delete the temporary branch.

After all PRs are processed, the temporary branch (stmp) is deleted.

5. Force-push the new squashed commit to the staging branch.

The squash-merged HEAD is force-pushed to project.staging_branch.
This makes the staging branch point to the new squashed commit that includes all batch PRs as one commit.

6. Mark and track the squashed commit for CI and status updates.

The batcher configures CI statuses and marks the batch as running.
Later, if CI passes, the squashed commit gets pushed to the target branch as the batch merge.