My gripe with the PR/MR model is how much more slower code refactoring on the fly is.

Code refactoring to me is like cleaning house. You need to do it everyday, and you need to do it often and in small pieces, one at a time, for maintaining a readable Git commit history,

That means multiple PRs/MRs with the intention of keeping the changeset small, often, with one MR depending on the other (why Github/Gitlab does not have a feature to automatically open multiple numbers PRs from each commit on a branch is beyond me) — as such I construct multiple PRs by hand on when I am on a “refactoring quest”.

But, if someone where to make a commit in the same area that I had worked on in the meanwhile, pandemonium, and that’s a ton of work for me to fix it.

My advice to teams is, if you are on a PR/MR model, do it for the sake of getting another person’s opinion on what you’ve done and not treat it as some sort of a “gate”. Do it pragmatically.

And yes, it requires a ton of discipline. I wont review an PR if it is not short, focussed, and does not have a descriptive PR message.