There are different ways to address feedback provided in the course of handling merge request. One is to push incremental changes, another is to maintain single [or same amount of] commit[s] throughout lifetime of merge request by force-pushing. Maintaining single [or same amount of] commit[s] past point of first approval makes reviewer's life harder than necessary. Well, formally speaking it makes life harder even prior first approval. Because maintaining single commit leaves no easy way for reviewer to "see" that there were no other changes besides those discussed. But approval is a check-point where reviewer has to make an overall assessment in either case, so maintaining single commit prior first approval might be considered acceptable. "Might" in previous sentence refers to the fact that life is compromise, and just formulated suggestion is not universal. In this case compromise is mostly about changes' complexity and size. I mean for big enough changes it might be inappropriate to maintain single commit at any step. [And reverse it true, from small, trivial changes it might be perfectly appropriate to maintain single commit all along.]

To summarize. Suggestion is to ask contributors is to abstain from maintaining single [or same amount of] commit[s] at least past first approval, but and consider incremental changes even prior that point. This doesn't preclude possibility that contributor can be asked to squash changes. On the other hand even though it's not explicitly proclaimed, the project reserves some freedom of editorial right to squash commit upon commit to repository. For this reason commits tagged with say "[to be squashed]" should be welcomed.