Assume I've got a PR stack with three branches.
Main <- API <- UI
There are two active PRs.
Main <- API
API <- UI
In parallel, I'm getting code review feedback on both PRs. My team members "Peer-API" and "Peer-UI" are experts in those areas and are doing the reviews.
I take a comment from "Peer-UI" and push a commit to the UI branch.
I take a comment from "Peer-API" and push a commit to the API branch.
The second commit forces a rebase of commits in the UI branch.
Now, my team member "Peer-UI" sees that a new iteration is published, so they want to look at what changed. They go to the files tab, click "All commits", and choose "Changes since your last review"...
...and it fails. The rebase destroyed the original commit they reviewed. Ther is no "last review" - the automatic rebase plus force push destroyed the commit history.
In this very simple example, "Peer-UI" can manually click the second commit to just see what changed in it. But as soon as you ramp up the total number of commits and PRs in the stack, it becomes a total mess. A reviewer can't even open commits they reviewed previously, let alone diff against them. Depending on what changes during the review, it may even be impossible to figure out which line of code any given PR review comment was talking about!
Forcing rebases and a linear history fundamentally prevents us from using stacked pull requests.
I propose that Stacked PRs need to support an entirely separate variant designed around using "git merge" (instead of "git rebase") with non-linear history - I call this "merge-mode".
When a stacked PR is created in "merge-mode":
- Child branches use "git merge" to take updates from the parent, not "git rebase".
- Linear history is neither required nor typical.
- Never a rebase, never a force-push.
I absolutely love the concept of stacked PRs. If they supported a mode that maintains complete (non-linear) commit history, they'd be extremely valuable. As-is, they are completely unusable; loss of commit history is a fatal limitation.
Assume I've got a PR stack with three branches.
Main <- API <- UI
There are two active PRs.
Main <- API
API <- UI
In parallel, I'm getting code review feedback on both PRs. My team members "Peer-API" and "Peer-UI" are experts in those areas and are doing the reviews.
I take a comment from "Peer-UI" and push a commit to the UI branch.
I take a comment from "Peer-API" and push a commit to the API branch.
The second commit forces a rebase of commits in the UI branch.
Now, my team member "Peer-UI" sees that a new iteration is published, so they want to look at what changed. They go to the files tab, click "All commits", and choose "Changes since your last review"...
...and it fails. The rebase destroyed the original commit they reviewed. Ther is no "last review" - the automatic rebase plus force push destroyed the commit history.
In this very simple example, "Peer-UI" can manually click the second commit to just see what changed in it. But as soon as you ramp up the total number of commits and PRs in the stack, it becomes a total mess. A reviewer can't even open commits they reviewed previously, let alone diff against them. Depending on what changes during the review, it may even be impossible to figure out which line of code any given PR review comment was talking about!
Forcing rebases and a linear history fundamentally prevents us from using stacked pull requests.
I propose that Stacked PRs need to support an entirely separate variant designed around using "git merge" (instead of "git rebase") with non-linear history - I call this "merge-mode".
When a stacked PR is created in "merge-mode":
I absolutely love the concept of stacked PRs. If they supported a mode that maintains complete (non-linear) commit history, they'd be extremely valuable. As-is, they are completely unusable; loss of commit history is a fatal limitation.