Why is a large/large pull request bad (or good)?

Question

git

The situation is this:
there were a lot of PRs in the intermediate branch, they were reviewed by the team to which the developer who made the PR belongs;
then all these commits / changes were merged into one PR and it became like a page with the contents of a book with dozens of commits, at the same time, developers from other teams joined the review and the review is delayed for several more days;

For me, such large PRs are a problem, I don’t understand how to review them, they look monstrous and defy understanding. And the question is - how to be in this situation? Is it worth asking for reviews from developers from other teams when there is a review in an intermediate branch, or should we leave this hell as it is?

PS The more detailed the answer, the better. You need to understand the topic as much as possible. Thank you )

Answer 1

there were many PRs in the intermediate branch, they were reviewed by the team to which the developer who made the PR belongs;
then all these commits / changes were merged into one PR and it became like a page with the contents of a book with dozens of commits, at the same time, developers from other teams joined the review and the review is delayed for several more days;

You need to decide where is whose responsibility. On a large team, every developer can't read every other developer's code. Therefore, you just need to make adequate commits / small PRs and review them, and if they are already reviewed, then do not pay attention to them, because it is not your responsibility now.
Why are you re-reviewing the same code, which is now merged into one big PR? What's the point? You have something wrong with the organization of responsibility.

Answer 2

Size matters, sometimes!
Your task is to have a pull request that matches your task.
If you changed the ORM, then this is one thing, but if you added a pink login button, then it’s completely different.
In my work it was both. 2-month work was thrown into the main branch, because it was necessary.
And there were little things because "here we all finished this unit"
Stick to the scheme when any operation in the git creates or fixes some kind of task

Answer 3

incomprehensible

It seems that this is the main requirement for PR - that it would be understandable.
And in terms of labor costs, does it really matter to you to review one big one or 10 small ones? That is, maybe the inconvenience is due simply to the unevenness of your load. You wait a month, then you need to review yesterday ... Then you should drown for this - for even distribution of the load, balanced business processes, efficient use of resources blah blah blah.