operations: Fix squashing commit ranges which contain empty commits

It has been reported by a customer that squash-merging commits in the case where the range of commits contains at least one commit whose diff is empty fails. This scenario can easily happen in case the diff has already been applied on the target branch. The root cause for this is the initial rebase: when rebasing our commits onto the target branch, the rebase iterator will return an error for every commit that has become empty.

Fix this bug by skipping commits which are empty: we don't really care about them, but only about the combined final commit containing all the other changes which haven't yet been included upstream.

Fixes #3740 (closed)