> Hiding away the development of a feature into one large commit makes it harder for people to review.
You have it backwards. One commit is much easier to review than three commits that you might not even know are related.
Assuming you know what you're doing, the commits you create with rebase are not large, they are just the perfect size. They contain the code needed for a single change and nothing else.
Sometimes a feature might actually take two or more commits, but then those commits represent two subfeatures... For example, you might first need to implement a new API, and then write a new feature that uses that API. That's two commits. If you forget something from the API or notice that it's problematic while coding the feature, then rebase will allow you to fix the first patch, instead of splitting code across multiple commits that make no sense separately.
One might argue that in this situation the feature patch makes no sense without the API patch but in fact it's a feature dependency, not a code dependency... As long as the API exists, the feature implementation is just fine as a standalone commit.
When used properly, rebase gives you freedom to use as many WIP commits and make all the mistakes you want in your private branch, while still allowing you to create good, easy-to-review patches that result in a logical, clean, and informative history.
If you still hold the opinion that rebase is bad, I am interested in further arguments, since the one reason you gave does not hold water.
You have it backwards. One commit is much easier to review than three commits that you might not even know are related.
Assuming you know what you're doing, the commits you create with rebase are not large, they are just the perfect size. They contain the code needed for a single change and nothing else.
Sometimes a feature might actually take two or more commits, but then those commits represent two subfeatures... For example, you might first need to implement a new API, and then write a new feature that uses that API. That's two commits. If you forget something from the API or notice that it's problematic while coding the feature, then rebase will allow you to fix the first patch, instead of splitting code across multiple commits that make no sense separately.
One might argue that in this situation the feature patch makes no sense without the API patch but in fact it's a feature dependency, not a code dependency... As long as the API exists, the feature implementation is just fine as a standalone commit.
When used properly, rebase gives you freedom to use as many WIP commits and make all the mistakes you want in your private branch, while still allowing you to create good, easy-to-review patches that result in a logical, clean, and informative history.
If you still hold the opinion that rebase is bad, I am interested in further arguments, since the one reason you gave does not hold water.