[u801e]

> Indeed, but trying to revert lots of tiny commits in one unit is no better.

You shouldn't have to revert a lot of tiny commits if the bug is due to just one of those commits.

> The result of a pull request should be the equivalent of having built a single patch to start with, just with better review tooling.

In my experience, features take more than one commit to implement. The merge commit provides a way to group those multiple commits so that you can see all commits that went into implementing a feature.

If you're trying to make pull requests that are like small commits, then a feature branch becomes

    first-commit
    first-pr-merge
    second-commit
    second-pr-merge
    third-commit
    third-pr-merge
    ...
    nth-commit
    nth-pr-merge

with commits and their associated merge commits for other features interspersed with your set of commits.

Which basically introduces a lot of merge commits (effectively doubling the number of commits) where the first parent is the previous merge commit and the second parent is the single commit for that pull request. You have no way to really group related commits that were used to implement a feature since there's no merge commit that groups them all together. In that case, you could halve the number of commits by dispensing with merge commits entirely and just adding the #PR-number in the commit message to link to the PR discussion.