You don't have to chain 8 PRs together, Github tries really hard to hide this from you but you can in fact review one commit at a time, which means you don't need to have a stack of 8 PRs that cascade into each other.
Yup, that's what my team does. It works wonderfully, and it fits well with Github's "large PR" mindset imo. It could be a bit better in the Github UI, but so can most things. I vastly prefer it to individually reviewing tons of PRs.
The funny thing about this debate for me is that i find it comes down to the committer. If the committer makes small commits in a stacked PR, where each commit is a logical unit of work, part of the "story" being told about the overall change, then i don't personally find it's that useful to stack them. The committer did the hard part, they wrote the story of changes in a logical, easy to parse manner.
If the story is a mess, where the commits are huge or out of logical order, etc - then it doesn't matter much in my view.. the PR(s) sucks either way.
I find stacked PRs to be a workflow solution to what to me is a UI problem.
I've seen that you can read one commit at a time, but never anything for reviewing (or diffing between them if they change) - is there a UI beyond just clicking on the list of commits?
Though I forget if you can even comment in the individual commits in that view. Complex multi-commit PRs have generally been a nightmare on GitHub in my experience.
You can comment on the individual commits' changes, but you can't comment on the commit (e.g. its message) itself. I believe you can do this in Gerrit.
Which means it's probably all I have seen - so you can't approve commits either, or track file-reading progress through commits (I think? i.e. "viewed file X at commit Y, but not at commit Z"), or diff changes to a commit (e.g. by order/message) after a rebase, just "you can see the current commit history". Not sure I'd consider that "can review one commit at a time", just "can read one commit at a time". "Review" means "there is support for this thing as a first class entity" imo, and that ain't what github is offering, nor anything even close to it.
That's true, but acceptance is still all or nothing.
When chaining commits it's possible to (for example) have a function that does THING and then have another PR that have a function that uses first one.
It's somewhat PITA when team has no-dead-code hard rule, but otherwise it's quite manageable and invites rich feedback. Reviewer and feedback can focus on atomic change (in example: function that does THING) and not on a grand picture.
Does that happen on merge or before PR creation? I thought the setting only applied it when you hit the merge button, so you'd still have commits prior to the merge. Though that won't help if someone pre-squashes them :s
Happens on merge, sure, but the end result is that you kinda lose the individual commits. You can still find them in the PR, but you won't see them in the git history, so git blame will just point you to the one big squashed commit.
If you, however, open a chain of 8 PRs, and merge them in the right order, the individual commits will be persisted in the git history. Potentially worth it if you like to have a "story" of several commits...
