Comment by mgfist
11 hours ago
Why are those not just separate PRs? Or if they really needed to be merged at once - they should still be separate PRs but on a feature branch
11 hours ago
Why are those not just separate PRs? Or if they really needed to be merged at once - they should still be separate PRs but on a feature branch
Why have PRs - groups of commits to pull - then if all you need is a single patch file?
You can, but most of us work in Github and having a PR to dump commits to is very easy and convenient. Then, when you get some feedback on your PR, you can dump more commits and it's very easy for the reviewer to see what has changed since the last time they reviewed it.
I feel like what you're arguing is that you should clean up your commits before anyone else sees them. Fair. But you could also clean it up right before merging to main. It's not that different, except the latter is much less annoying, particularly when going back and forth with people.
I know this is a very github centric workflow, but that's where most engineers work now, and it's nice and easy. This wouldn't work for eg: contributing to linux, but that's not what most of us do.
This is where the "Trunk based development" people live - I personally believe that commits should be atomic, because git bisect on smaller meaningful commits is a hang of a lot better than a monster 90 file change commit