Atomic Commit Convention
Please see https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention
As with almost anything, there can be exceptions to this general principle. Basically it means do not combine unrelated code changes (ex: two different bug fixes or feature additions) or a lot of code changes (even when related) into a single commit.
Even combining similar bug fixes (say undefined keys) in a single merge request to review together, rarely makes sense: If any change is rejected it blocks the entire MR, and if two changes lead to discussion it can make comment threads very confusing.
Similarly, if one commit depends on another (otherwise, it breaks Tiki), they need to be done as part of a single MR (And they can be squashed) Ex.: https://gitlab.com/tikiwiki/tiki/-/merge_requests/5643#note_2080601822
It is different but a similar idea to an Atomic Upgrade. Ex.: You can revert both easily.
On average, each commit has a tiny chance to have an undesired outcome. So being able to revert is a good thing. Similarly, atomic commits make it easier for merging code between branches (ex.: A backport)