What is the recommended approach for creating stacked patches in GitHub Pull Requests (PRs)?
Based on the discussion in Discord, it seems that I should follow these steps:
Create branches in the upstream repository for each of the patches.
Set up a sequence of PRs that are daisy-chained, with the following merge destination:
Patch #1 → main
Patch #2 → Patch #1
…
Patch #N → Patch #N-1
When it’s time to merge, first merge the PR for the first patch.
After merging the first PR, change the destination of the i-th patch to ‘main’ and then proceed to merge it.
Is this the correct and recommended method for handling stacked patches in GitHub PRs?
smeenai
September 12, 2023, 7:33pm
2
There’s been a bunch of discussion in Write a guide for doing "Stacked Reviews" with GitHub Pull Requests · Issue #56636 · llvm/llvm-project · GitHub , though it hasn’t reached any conclusion yet. In particular, any stacked PR mechanism will require the ability to create branches in the llvm/llvm-project repository instead of your own fork, which we don’t have agreement on yet.
1 Like
So, since there is no agreement on creating branches in the upstream, should I just create patches that contain commits that they depend on? And specify this in the PR message.
A few people are trying this already e.g. [TableGen] Use buildConstant to emit apply pattern immediates by Pierre-vh · Pull Request #66077 · llvm/llvm-project · GitHub . Linking them in the PR message or a comment means they show up as mentioned in the other PRs which is a nice side effect.