Why are you interested in looking at individual commits? What can you possibly learn from that that you can't get from looking at the entire diff the PR is introducing?
Does your CI test each individual commit? Afaik most of them only test the top commit. How do you know/enforce that all the inbetween commits also build/pass tests?
How do you know how many commits to revert, if you need to revert the feature? Instead of reverting 1, now you have to revert N where N is not recorded anywhere.
Why are you interested in looking at individual commits?
Because they can explain their individual rationales, while still making the most sense to merge all together.
What can you possibly learn from that that you can't get from looking at the entire diff the PR is introducing?
Ease of review (both before merge, and in the future when wondering why something was done a certain way). Saves me as a reviewer from having to guess which parts of the commit are meant to do what.
This, of course, means that every commit needs to be a reasonable change in itself -- fixup commits done while developing should be squashed into the original change with a local rebase (these are the "meandering" commits your parent post mentioned).
How do you know/enforce that all the inbetween commits also build/pass tests?
I'm no CI expert, but I would hope that most systems allow this as an option.
How do you know how many commits to revert, if you need to revert the feature? Instead of reverting 1, now you have to revert N where N is not recorded anywhere.
It's recorded in the merge, assuming you always make a merge commit.
Otherwise, since each commit is actually its own logical change, you figure it out the same way as you would figure it out in the "squash PR" model -- bisect to find it, then see if reverting it helps.
Comments
Why are you interested in looking at individual commits? What can you possibly learn from that that you can't get from looking at the entire diff the PR is introducing?
Does your CI test each individual commit? Afaik most of them only test the top commit. How do you know/enforce that all the inbetween commits also build/pass tests?
How do you know how many commits to revert, if you need to revert the feature? Instead of reverting 1, now you have to revert N where N is not recorded anywhere.
Because they can explain their individual rationales, while still making the most sense to merge all together.
Ease of review (both before merge, and in the future when wondering why something was done a certain way). Saves me as a reviewer from having to guess which parts of the commit are meant to do what.
This, of course, means that every commit needs to be a reasonable change in itself -- fixup commits done while developing should be squashed into the original change with a local rebase (these are the "meandering" commits your parent post mentioned).
I'm no CI expert, but I would hope that most systems allow this as an option.
It's recorded in the merge, assuming you always make a merge commit.
Otherwise, since each commit is actually its own logical change, you figure it out the same way as you would figure it out in the "squash PR" model -- bisect to find it, then see if reverting it helps.