RFC: `bors r+ squash` to squash commits in a *specific* PR

Summary: Add bors squash command to squash a specific PR. Unlike the existing use_squash_merge option, this will allow to select squash or merge on the case-by-case basis.

I allow this RFC document to be modified and redistributed under the terms of the Apache-2.0 license, or the CC-BY-NC-SA 3.0 license, at your option.

Motivation

Some projects want to maintain a "clean" commit history on a best-effort basis. For example, for open source projects maintainers typically pay a lot of attention to crafting a good sequence of commits for a pull request, while less experience contributors often end up with "semanticless" merge and fixup commits. For these cases, it would be useful to merge one PR as is, and squash the other down to a single PR. It is possible to ask the contributor to do the required git fu, but this is pretty hard and discouraging, there's no reason why a robot can't do that!

Note that today, using the use_squash_merge option, it is possible to squash all pull requests. This solves the fixup commits problem. However, it prevents expert git users from creating a good multi-commit history for larger PRs.

Guide-level explanation

Add squash modifier to bors r+ / bors merge, such that it also squashes all PR's commits to one.

Reference-level explanation

Grammar: bors r+ [squash]

Drawbacks

  • this adds one more choice the user can/has to make for every PR.

Rationale and alternatives

TBD

Prior art

  • When merging PR via GitHub UI, there's a similar squash and merge option.

Unresolved questions

  • What is the interaction between bors squash and use_squash_merge? Do we need a nosquash modifier to supress squashing in a specific case when use_squash_merge is set to true?
  • Should bors squash be supported as a shorthand notation for bors r+ squash?

Future possibilities

TBD

See also

Tracking issue: https://github.com/bors-ng/bors-ng/issues/1028

1 Like

How does it interact with PRs that aren't squashing during merge? This sounds like it could
really complicate the merging code.

As a user of bors, I'd expect that any PRs that are being squashed wouldn't be able to be batched with other PRs. Either that, or you would end up with a linear branch with one commit per batched PR.

I would like something at the opposite.
We use use_squash_merge by default, but for some long feature branch, we would like to "rebase and merge" it.