Support "Rebase & Merge"

[rami3l]

@rust-lang/rustup is considering the possibility of introducing a merge queue into rust-lang/rustup. However, as we are currently doing GitHub-native "Rebase & Merge" operations, I wonder if the same workflow could be made possible with bors ¹.

Possibly related to #25 (comment).

Footnotes

1. This is already possible with GitHub Merge Queues. If the plan was to use it as the backend of the new bors (https://github.com/rust-lang/bors/issues/25#issuecomment-1588696609), then maybe we can go for it first. ↩

[albertlarsan68]

The issue is that in order for GitHub to mark the PR as merged, the head of the PR branch must appear in the base branch. GitHub can work around that because they are GitHub.
Bors-ng had the same problem, they solved it by simply closing the PR and prepending [ Merged by Bors ] to the PR title, but this has the drawback of messing up the stats.
If Bors is able to push to the PR, then it could force-push the PR, then push to main, but this is kinda hacky, and doesn't work if the "Allow pushes by repo maintainers" box is unchecked.

[Kobzol]

Hmm. But this issue also exists with merges, right? When homu now performs a merge on the auto branch, this merge commit is created outside of GH, yet GH recognizes that the PR has been merged.

[albertlarsan68]

This is because the head of the PR becomes reachable from the head of the base branch, but if rebasing is done, the commits are not the same. Also, I tend to personally dislike having something creating commits in your name, or the primary reason that GitHub displays "Unverified" next to the commit, or "Partially Verified"

[Kobzol]

Ah, it needs to be reachable, that makes sense. I'm not sure why GH always creates new commits, AFAIK even if it could be a fast-forward. In any case, this would not be practical for bors.

[rbtcollins]

For Rustup, the requirement around what sort of merge to do was pragmatic, not opinionated: Kinnison needed to be able to write up the release notes and link back to the PRs that were merged, and both rebase and squash merges prevented this being easy in some fashion. So as long as whoever is doing releases can generate good release notes (e.g. tell which PRs were merged in the release), the merge style doesn't matter.

[rami3l]

(Slightly off topic)

@rbtcollins In that case, I guess GitHub can pretty much do that quite easily for us regardless of the merge method being used. There is a "generate release note" stuff that I have used in my own projects (where I also use "Rebase & Merge" quite often), we can choose to copy the generated contents into CHANGELOG.md.