Hi Dave,
I'm wondering what pain you are feeling around having multiple patches.
From my perspective it is much easier to deal with smaller commits as it gives us a quicker way to understand each change if we want to look back at history. I agree that each patch should work standalone (tests should be passing, the application should run.) But, I think aiming for a patch size that encompasses an entire feature is often too large.
When we were squashing patches and then having to go back and modify them, we were spending a large portion of our time managing patches and branches rather than working on code. With smaller patches, rebasing is much simpler and easier to understand. So I'd really like to be able to continue to do things this way. I do understand the desire not to have a 'bad' commit on master.
Can you explain how having a large number of patches impacts your process and maybe we can together come up with a process that works better for all of us?
E.g. if you just wanted to review all the changes at once, you could do `git apply *.patch` to review, and then `git am *.patch` when you are ready to commit the changes.
Thanks,
Tira
