Better handling PRs with dependencies

Development
#1

This might become an RFC.

In Mir we reasonably often have a situation where, in order to get some feature work done, we must first do a bunch of other, semi-related feature work first. To make reviewing (and later bisecting) easier, we tend to make these a bunch of different branches and have PRs with the base-branch set like so:

master -> A -> B -> C -> …

This works OK, except that if you have bors set to delete merged branches then after A is bors-ed and merged into master the base-branch of B is deleted, which irrecovably closes the B->A PR.

It would be nice if (and it seems that GitHub exposes enough API to) bors would merge A, change the base branch of B to master, and then delete A.

As an extra bit of ergonomics, it would be even better if bors r+ on the dependent branches would be deferred until the base branch was master - so given the PR stack A -> B -> C -> D you could review B and have A -> B (bors r+) -> C -> D and it would wait there until A was merged, then it would also merge B.

Update base branch of PRs depending on a branch that will be deleted
#2

Shouldn't bors be merging backwards? Like, merge D -> C -> B -> A -> master?

#3

Hi @psunkara, that is one option, but that depends on your policy, really.

If you wanted nested merges like that, it would actually end up as a single merge commit on the master branch. If you're OK with that, the missing bit in bors today would just be deferring until the D is merged in A.

What we're looking for, is for each of A…D to end up as merge commits on the master branch, in that order. Which is why we'd need a bit more from bors.

1 Like