Let me explain it to you from a developer to a developer.

Imagine you have a battle-proofed, elegant piece of code called the Italian Constitution. There is nothing inherently wrong with the code, only some minor issues.

Imagine that a colleague of yours (which we’ll call Matteo) raises a Pull Request to address those issues. Matteo also takes the opportunity to modify a third of the entire code base.

The Pull Request is huge. Reviewers struggle to do a good job. The Pull Request contains a few good elements: it reduces computational costs for heavy operations, it removes some dead code and fixes a few bugs. At the same time, though, it introduces new bugs, modifies some crucial code paths in a confused way and introduces some unclear behaviours. There are even a few lines of code which look like some kind of a back-door.

You and your colleagues complain about the Pull Request and suggest Matteo to reduce the scope of the changes. You also suggest some amendments. Someone suggests an alternative, easier, way to address the initial issues with a trivial config change, which would make the Pull Request superseded.

The author goes nuts. He claim to be the only one in the Company who understand about code. He refuses to apply the config change in production or to even accept the suggested amendments to his Pull Request. The Pull Request is there, merge it or decline it. Things escalate. Matteo declares he would quit the Company if the Pull Request is not merged as it is.

The marketing department sends an email to all developers asking them to merge the Pull Request.

Would you merge that Pull Request?