Rebase a pull request

Support
#1

Hello,

I am trying to understand if bors is able to rebase a pull request and then merge commit.

I couldn’t find much about it in the documentation, but maybe I am looking in the wrong place…

Cheers

L

2 Likes
#2

Bors doesn’t have support for this yet. If you were looking at the reference manual, then you were looking in the right place.

#3

Would that be a welcome feature request / pull request to open? I've been pondering this the other day and I even have a short write-up of how I imagine this could work. Here it goes:

TL;DR: let’s add a rebase_before_merge option that, given a batch PRs, for each of them:

  1. rebases the PR on the staging branch

  2. does a separate merge commit for that PR on the staging branch

  3. leaves a ‘[build batched]’ marker in the merge commit message of all but the last PR in batch

This would result in just 2 ‘swim-lanes’ in the git log of the target branch, one being merges (PR boundaries), the other - actual changes. No more hard-to-track, confusing branch spaghetti.

If having merge commits that were not built in CI is a hassle, instead of (3.), we could make a separate merge commit for the whole batch whenever there’s more than one PR. That would lead to 3 swim-lanes occasionally (for each batch having >1 PR), but would hold the ‘each merge commit was built in CI’ property.

Would a PR with such/similar a feature be accepted? I guess, we should consider this write-up a feature request :slight_smile:

The default github workflow, followed by bors, is to just do a an empty merge commit. This leads to a very 'non-linear' and hard to track git log, with numerous branch lanes slithering next to each other.

Some prefer a rebase-based workflow, where the commits from a PR are put on top of the target branch and no merge-commits are done. This has the advantage of a linear history and commits from a single PR appearing close to each other, but somewhat blurs the PR boundaries. Which is the main concern of the opponents of this approach in my experience.

I'd like to propose a feature that allows a workflow that reaps benefits of both of the above approaches: rebase before merge. The idea is: all the batched PRs are non-conflicting with the target branch (and each other) anyway, so we just rebase subsequent PRs on the staging branch before merging them. We do an additional merge commit on the staging branch between each two PRs in the batch to demarcate them. We do the rebase just locally, so this requires no additional privileges.

The result is a linear history of changes in the target branch, with just two 'swim-lanes': one for merge commits, and one for the actual changes. Each PR's commits are in a contiguous sequence, each PR is further demarcated by a merge commit mentioning its number.

Would a PR with such/similar a feature be accepted?

#4

I should probably get around to actually making the RFC process official, since this seems like a prime use case for it.

#5

Okay, I’ve got the forum section and the initial write-up of the process. So, yeah, it’d be nice if you opened a topic following the RFC template in this category. Your writeup has a lot of the necessary content in there, it just needs to be categorized correctly.

#6

Hi !
I'm interested with this feature. How do you deal with it in other projects ?
Before bors, our process was to

  • ensure the PR is validated (manual check + CI)
  • rebase before merging if necessary
  • merge once CI is OK

Bors could allow us to skip the rebase part, and to simplify the merging management when there are many PRs to deal with, but at the expanse of a messier git history.
Is a manual rebase before bors r+ the way to go ? Or do you all skip the rebase part ?

Thanks