In my experience, the “small change” merge requests tend to be the most consequential.
Sure, they look harmless, but it’s all the external pieces (not shown in the diff) impacted by the “small change” tend to make such a disaster.
Sure, they look harmless, but it’s all the external pieces (not shown in the diff) impacted by the “small change” tend to make such a disaster.
This is the sort of thing that's difficult to argue economically for studying with proper randomisation and everything, but an observational study can be made on open source repositories (even in projects where the main contributors are on a corporate payroll) fairly easily with LLMs these days. I wish I had more time to pursue things like this...
I think you're confusing things. The "small change" refers to the diff size. It's far easier to review a one-liner because the impact analysis is limited to that local change.
Of course if your change is something like "mutex.lock()" or "rm -rf *" then these changes will be more consequential than 500 files worth of whitespace changes.
The tiny 2 or 3 line change that fixes a problem doesn’t always get the same critical thought process.
When it crosses subsystems rarely crossed, there are often nasty surprises.