We've all encountered those legacy code bases that are years old and thoroughly spaghettied. Ideally, you'd like to go through, reformat it all, leave comments throughout, and generally make the world a better place. However, a "useless" commit like that probably opens the code up to merge conflicts and other problems everyone else will get on your case about.<p>So how have you solved this problem in the past?
> However, a "useless" commit like that probably opens the code up to merge conflicts and other problems everyone else will get on your case about.<p>That is a social problem not a technical one.<p>You need to sell the idea to your team to try to improve the code base with every commit you do. Every time you need to make changes in some source file, see what clean up you can do to it as well.<p>Depending on the morale/motivation/priorities of the team, this can be a harder sell than it should be.<p>Lead by example. Show good judgement on how much to do. Small changes accumulate fast. Don't upset/hinder people by changing vast tracts of code that they need to work on.<p>As a great VP of Engineering I once had the fortune to work with told me: Software engineering is a team sport.
It's an office politics issue. Here we have little issue with it, but I worked in a place that didn't like handling lots of "clean up" commits. The main issue is (working in embedded avionics systems) code changes have to be peer reviewed and qualified. So I've tried to make sure my changes are part of some new or existing PR. I can't do it willy-nilly or I'll be asked, "Why did foo.c:145-150 change?" If it's not part of a PR I can't justify it. So when I stumble on problems, I put them in JIRA. Even if the "problem" is: 200 lines of code without a single comment, all variables have names like XYZ12, XYZ13. It may technically work, but no one knows why and, fortunately, falls afoul of our coding guidelines. I may not be able to work it today, but it's in the system and can be worked at some point when priorities align better.
How do you eat an elephant? One bite at a time.<p>Sure, a mass refactoring is going to cause a lot of pain to merge in, but you shouldn't be making massive pull requests in the first place. I don't think small refactoring here and there should be an issue. It's not like we've never dealt with merge conflicts before.<p>If your company is discouraging refactoring because it will cause merge conflicts, that's probably not a good sign of things to come.
Refactor code while no one else is working on that module, and ask everyone to pull/update once you are done so they start their changes post-refactoring.