Allow controlling squash behaviour by using a bors command

[carlos-granados]

Summary: allow controlling squash behaviour by using a bors command

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

The new config option to allow using squash and merge instead of a simple merge is great but it is an "all or nothing" option. Either all PRs are squashed of no PR is squashed. It would be great if this behaviour could be also controlled by issuing a bors command, allowing you to override the default behaviour for a single PR

This will be specially helpful when by default you are squashing all merges but there is a PR where you want to save the commit history

Guide-level explanation

There will be two new bors commands:

bors squash on: this will turn "squash and merge" on, even if the config option is off
bors squash off: this will turn "squash and merge" off, even if the config option is on

This commands will be issued before starting a merge with bors r+ or an equivalent command

Reference-level explanation

This command should override the default value read from the config file. The behaviour of the merge code will be the same as though the corresponding value had been set using the config file.

So using bors squash on will be equivalent to having use_squash_merge=true in your config file for this PR
And using bors squash off will be equivalent to having use_squash_merge=false in your config file for this PR

• How the feature interacts with other features.

This command is just an optional override on the use_squash_merge config option. We need to make sure that it only affects the current PR. So we may need to decide how to handle the case when bors-ng is trying to batch merge several PRs. The preferred behaviour would be to squash all PRs and only not squash those where we used bors squash off (or the other way around if we use bors squash on)

Drawbacks

If we cannot separate the behaviour for different PRs when doing a batch merge, this may not be desirable as one option in one PR could affect several other PRs

Also some organizations may have a policy of only squash and merge or never squash and merge and this would allow the users to bypass this policy

Rationale and alternatives

If we don't do this, some users may not want to use the squash and merge option as they may want to preserve commit history in some cases and this may prevent them from adopting bors-ng

Prior art

No prior art that I know of

Unresolved questions

• How to properly handle batch merges with this option

Future possibilities

Can't think of any

[MarkRobinson]

I don't like it the way it is.

An org would turn squash merging on/off for a reason so allowing users to bypass it would be a serious issue.

What I think think would be better to have:

default_merge_method: squash | git-merge | other
allow_squash: true|false (default: true)
allow_git_merge: true|false (default: true)

[DilumAluthge]

In my opinion, this RFC adds too much complexity.

In particular, what happens to batching when you have some PRs with "squash on" and some other PRs with "squash off"?

What is the use case for sometimes squashing and sometimes not squashing? I feel like the vast majority of people will either want to always squash or never squash.

[xmo-odoo]

What I think think would be better to have:

Having individual flags to allow integration methods seems less than ideal if the merge methods are extensible. Having it be a whitelist of allowed merge methods might be more sensible

[kevincox]

In particular, what happens to batching when you have some PRs with "squash on" and some other PRs with "squash off"?

This seems fine to me. It would work like this:

git reset --hard main
git merge non-squash-pr
git cherry-pick ...squash-pr
git merge other-non-squash

Obviously the cherry-pick isn't actually sufficient as you would need to clean up the message but I think the idea comes across.

Basically it would be equivalent to doing the operations one-by-one.