Building on this, I see a lot of areas of code that are effectively untouchable because of how much energy would need to be invested to understand the code and

Building on this, I see a lot of areas of code that are effectively untouchable because of how much energy would need to be invested to understand the code and its context before making a change. So if a change has to be made to fix a bug or add a required feature, it's done in the most low-impact way, which only makes the code that much harder to understand in the future. Meanwhile, I can't get refactor-only commits through because nobody wants the code to be touched unless absolutely necessary. We're in the middle of migrating a massive PHP codebase to Java. The code I'm talking about is newer Java code. In a few years, people will be wondering why the Java code is as much as a mess as the PHP code and, if I happen to still be around, my response will effectively be "I told you so" (in kinder, more productive terms). I've basically determined that my only option to ensure continued or improving code quality is to combine refactoring and bug fixes in the same merge request, while still keeping them in separate commits. That way whenever I touch a part of code for bug fixing or whatever else, I leave it behind in much better state than it was before.