3 ms·
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 change
by noident 6mo 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...
- Hamuko 6mo agoYeah, I feel like just being able to review a PR commit-by-commit with a nice interface would just suffice.
- ezekg 6mo agoNot 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.
- aunderscored 6mo agoHow does that differ from this where you need to keep track of state and the whole change in the stack?
- ezekg 6mo agoIf we're speaking strictly code review, because you can actually make sense of the changeset for the child PR by not including its unmerged parent's changeset.
- benatkin 6mo agoFor me that would mean avoiding tiny commits, and I wouldn't want to do that
- jaredsohn 6mo agoThere 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.
- bombcar 6mo agoSo much effort has been spent beating git until it's just CVS with bells on.
- steveklabnik 6mo agoThe stacked diffs flow is much closer to the kernel flow for git than the traditional GitHub PR flow is.
- landr0id 6mo agoPart 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.
- noident 6mo agoWhat can stacked PRs do that a series of well-organized commits in a single branch can't?
- steveklabnik 6mo agoStacked 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.
- a_e_k 6mo agoI think the point the GP was trying to make is that the GitHub UI ought to be able to allow you to submit a branch with multiple well-organized commits and review each commit separately with its own PR. The curation of the commits that you'd do for stacked PRs could just as easily be done with commits on a single branch; some of us don't just toss random WIP and fixup commits on a branch and leave it to GitHub to squash at the end. I.e., it's the GitHub UI rather than Git that has been lacking. (FWIW, I'm dealing with this sort of thing at work right now - working on a complex branch, rewriting history to keep it as a sequence of clean testable and reviewable commits, with a plan to split them out to individual PRs when I finish.)
- pertymcpert 6mo agoWhat might that be?