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...

▲

landr0id 9 hours ago | parent | next [-]

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.

▲

noident 8 hours ago | parent [-]

What can stacked PRs do that a series of well-organized commits in a single branch can't?

	▲	steveklabnik 7 hours ago \| parent [-]
		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.

▲

jaredsohn 9 hours ago | parent | prev | next [-]

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.

▲

bombcar 9 hours ago | parent | prev | next [-]

So much effort has been spent beating git until it's just CVS with bells on.

	▲	steveklabnik 8 hours ago \| parent [-]
		The stacked diffs flow is much closer to the kernel flow for git than the traditional GitHub PR flow is.

▲

Hamuko 9 hours ago | parent | prev | next [-]

Yeah, I feel like just being able to review a PR commit-by-commit with a nice interface would just suffice.

▲

ezekg 9 hours ago | parent | next [-]

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.

▲

aunderscored 8 hours ago | parent [-]

How does that differ from this where you need to keep track of state and the whole change in the stack?

	▲	ezekg 8 hours ago \| parent [-]
		If 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 9 hours ago | parent | prev [-]

For me that would mean avoiding tiny commits, and I wouldn't want to do that

▲

pertymcpert 9 hours ago | parent | prev [-]

What might that be?