Nikolaus Piccolotto

I actually like your idea of approving a tuple `(base commit id, diff)` instead of the PR head commit. It would also solve another issue: Currently we rely on knowing...

@ePaul _(Without understanding your point/proposal)_ > Or create this branch, but push it with an already approved commit id. That was wrong and probably confusing. I suggested the following: Workaround...

> About the confusion: If I understand it right, this feature proposal says this: I got the same impression, so yes. > Second, a possible objection With "commit comment" do...

> If by 6 you mean approved by Zappr then it's fine. I do. > If this feature works the same for push -f, then it's great. Currently you can...

> If I change the branch ref to another commit, i.e. I force pushed, does Zappr still count previous approvals? No, but you could approve afterwards as well? I agree...

Okay, so we're back at the beginning, except we now know that there is no workaround for you, as far as I understood. To reiterate: I think it's a good...

Update on this: Reviews are now supported in the web hooks :tada: However in order to replace our existing workflow we also need "require reviews before merging" to be in...

> @lukasniemeier-zalando: But can we support "zappr approvals" inside the native reviews?  Yes.

So to give an update on this. Technically it's now possible to integrate native approvals into Zappr. However preliminary testing revealed some oddities about GH approvals, like this one: ...

Ahh, thanks for asking ❤️ So probably it will "just work" one day without prior announcement :grin: