You try by testing. Take big software like Firefox as an example. There are hundreds of commits landing on a good day and to merged into moz central you need to submit the patch for review and testing. Once the code is merged there are more testing and if something broke along the way the release team will figure out ans backout the bad commits or get someone add a fix asap. It is important to not be afraid to merge but also be responsible for your code. Take major refactoring as an example - don't create a patch which is partially implemented with breakage. You can ask for review but don't request a merge knowing it will break - actually your tests should tell you that. Finally, it is important to communicate changes regularly. Developers shouldn't be suprised to see their changes broken because someone else decised to refactor all the sudden.
I understand that testing tells you you broke the trunk, so you didn't break up the feature into small enough merge-able pieces. My question is what happens if you can't break it up any smaller--do you just throw up your hands and say you can't implement the feature because there's no way to break it up into small enough pieces?
You can bulk delete a bunch of functions and won't break anything. Your patch may require changes to 30 files but the change is minor. "Small enough pieces" is ambiguous I admit. I think a better way to put it to work is make your patch enough to get your code reviewed. If there are drastic changes, just let people know what you are planning to change (really, write out your plan). You may have to write wrappers or keeping the original function intact but write a my_api_function_2 for the newer version so people can start adopting it.
