Comment by noident
12 hours ago
If only there were some way to logically break up large pull requests into smaller pieces... Some way of creating a checkpoint with a diff including your changes, and some kind of message explaining the context behind the change... some way to "commit" a change to the record of the repository...
Part of the idea behind stacked PRs is to keep your commits focused and with isolated changes that are meaningful.
A stacked PR allows you to construct a sequence of PRs in a way that allows you to iterate on and merge the isolated commits, but blocks merging items higher in the stack until the foundational changes are merged.
What can stacked PRs do that a series of well-organized commits in a single branch can't?
Stacked PRs tend to encourage a series of well-organized commits, because you review each commit separately, rather than together.
What they do that the single branch cannot is things like "have a disjoint set of reviewers where some people only review some commits", and that property is exactly why it encourages more well-organized commits, because you are reviewing them individually, rather than as a massive whole.
They also encourage amending existing commits rather than throwing fixup commits onto the end of a branch, which makes the original commit better rather than splitting it into multiple that aren't semantically useful on their own.
1 reply →
There are tools that use LLMs to do this.
I've done this manually by building a big feature branch and asking an LLM to extract out functionality for a portion of it.
For the former, it would seem to split based on frontend/backend, etc. rather than what semantically makes the most sense and for the latter it would include changes I don't want and forget some I do want. But I haven't tried this a lot.
So much effort has been spent beating git until it's just CVS with bells on.
The stacked diffs flow is much closer to the kernel flow for git than the traditional GitHub PR flow is.
Yeah, I feel like just being able to review a PR commit-by-commit with a nice interface would just suffice.
Not really. Without seeing the entire changeset for a PR, you'd have to mentally keep track of what the current state of everything is unless you're a commit minimalist and presquash.
How does that differ from this where you need to keep track of state and the whole change in the stack?
1 reply →
For me that would mean avoiding tiny commits, and I wouldn't want to do that
What might that be?