A better fix is to abandon the whole "pull request" model used by github (and copied by a lot of others, like gitlab, etc.), and use a proper code review system (gerrit, etc.) instead.
But of course that's not a "quick" fix.
But of course that's not a "quick" fix.
Say you are the reviewer, you gave some feedback for the author to address. The author says they addressed them and asked for your review again. How do you review that? Of course you can just review the whole change again, but if it's a huge change and you only asked a few small parts to be changed, it would be hard to make sure the rest are still the same. How in Github's PR model can you see the diff between the 2 states of a PR? The only way is for the author to push a separated, "fixup" commit to the review branch, so you can just view the diff of that commit. But that creates those "fixup" commits that's not useful in the final merge, so you will want to use squash merge in the end, and using squash merge means that the final commit message is totally up to the people clicking the merge button and others have no control over that. In gerrit, commit messages are part of the code that you can review and leave feedback, a change is always a single commit, and there's builtin feature to show diff between the 2 states of a change.
Another example is when you have a change (B) depending on another pending change (A), and there are some feedback on change A you need to address, and it would be a whole mess on how you also update change B to make sure that changes of A do not show up in the diff of B.
I can't speak for GitHub, but GitLab allows you to easily compare previous versions (states) of a branch. Whether you push additional commits or squash them locally and force push to update the remote branch, the differences between versions are easy to compare.
https://docs.gitlab.com/ee/user/project/merge_requests/versi...
This is super easy with SmartGit and it works with any Git host.
The Branches panel lists both my local branches and all remote branches. I double-click the remote branch and it offers to create a local branch for it.
Then I can compare any two commits by simply clicking one of them in the Graph (log) panel and Ctrl+click the other one I want to compare. Whenever two commits are selected, the Files panel lists the files that changed between the two.
Click any of those files and the Changes panel shows the changes between the two commits. Double-click the file to open a more full-featured compare tool such as Meld.
The Branches panel has a couple of other great features: a list of your stashes, and a Recyclable Commits checkbox. When you turn on any of those, their commits appear in the Graph panel just like any other commit.
So if you've really messed up, instead of having to trawl through the reflog and checkout a commit you think might have the code you need, you can just click around and view any reflog commit or compare any two commits. Same for stashes. Instead of all these special cases, every kind of commit is unified into one consistent model.
Gerrit is a CR tool only (OK, it also hosts you repositories) and I've found that its UI allows me to focus on the code being reviewed much better than Gitlab. There are multiple maybe small things (navigation patterns, keyboard shortcuts, they way the information is provided) but all together make a tangible difference, one of reason being that reviewing someone other code is not an easy one and any obstacle will make it more mundane and lead to very shallow reviews.
I've found that a commit-based review process (although it is not enforced, i.e. a developer can push whatever number of commits and then ask for a review/assign reviewers) is much (much) better than the PR/MR model. I think it nudges developers into a) more though-out commits, b) smaller commits, c) pushing early and getting early feedback. Probably the fact that we are working with a bit unnecessarily complex branching model now makes things worse, but even without that I think that an effort to push changes (especially smaller ones/small fixes/small improvements) is (much) smaller in Gerrit.
There is one oddity with Gerrit, namely so-called 'Change-Id' (the way Gerrit tracks new revisions) - nothing unmanagable, but it probably will make you trip a few times at the beginning. And likely you will need to learn Git a little better (in general you will need amend/rebase to apply changes after your colleagues commented on them). If you are using any of JetBrains IDEs there is a very good plug-in, which also allows to easily fetch changes you are asked to review. All in all in the past decade we were able to on-board all new hires without much pain.
I still like many other bells and whistles provided by Gitlab (and likely Github), especially build pipelines. I would like to find some time to try to 'integrate' Gerrit with Gitlab - Gerrit can easily push changes to other Git repository, so I can imagine it would be possible to plug into build pipelines etc. etc. Yeah... so many things to do, so little time ;-)
Edit: One more thing - it is mentioned by fishywang below/around - I've just read his comment and facepalmed about myself why I didn't listed it as well - tracking comments/discussion/changes/revisions/diffs - this may be the biggest advantage of Gerrit - really, maybe I don't know how to use Gitlab properly, but this aspect there is really weak.