I know this, and I suspect the person you replied to also knows this, but I have never in my career as a programmer found anyone whose review I needed, who would have been comfortable doing this without my help.
I haven't always been working with "best and brightest" although that's not a dig, as the people I'm working with now are probably in the top 0.001% of Git users, nobody who does not work on Git as a discipline in and of itself can live up to this standard.
> I know this, and I suspect the person you replied to also knows this, but I have never in my career as a programmer found anyone whose review I needed, who would have been comfortable doing this without my help.
Well, i wouldn't say never, but you are spot on about the rest!
Many don't want to deal with the additional cognitive load. Of course, not everyone uses GitHub either: as far as i know, GitLab doesn't really have good UI for stacking merge requests (their terminology for the equivalent of GitHub's pull requests) and as a consequence you end up having to write comments about the order in which things should be reviewed.
Now, admittedly, i've personally done it in cases where it makes sense (e.g. separate bunches of refactoring or preparatory work from the introduction of new features), but it was definitely the exception, not the normal way of doing things.
I feel like if i started stacking my changes, some of the more established developers would furrow their brows and complain in the stand-up about needing to spend extra time on review, as they have in the past. Essentially, it's not enough for an idea to be good (or at least a good fit, given its drawbacks), but you also need to read the room!
I haven't always been working with "best and brightest" although that's not a dig, as the people I'm working with now are probably in the top 0.001% of Git users, nobody who does not work on Git as a discipline in and of itself can live up to this standard.