Why Gerrit is accepting pushes, it can't handle?

Question

Following comments to this answer and information if Gerrit's docs. If adding proper refs is mandatory:

git push gerrit HEAD:refs/for/master

Then why Gerrit is accepting at all a push without them? After doing git push origin master with proper refs missing, push is accpeted (at Git level), but no change is created (at Gerrit level). User is ending up with a mess in code review system (can't merge non-existing change, can't push nothing else, because he or she is getting no changes reject) and must do a lot of strange things to fix this problem.

What is the reason or logic for implementing a feature, that such commit will be accepted? Why Gerrit isn't rejecting pushes, that it can't handle at all?

Answer 1

you can create a push rule in Gerrit Administration page, where you can disable the direct push. see the details here in my team it is useful to have two groups with different push rules. The groups working on the same branch, but only one of the group introduced the Gerrit workflow. But that does not mean that the commit or changes would cause a mess because of pushed in different way to remote barnch. Gerrit/Git will handle it by rejecting non-fastforward changes.

Answer 2

If a user has sufficient permissions (specifically a Push permission that covers the refs in question, in this case refs/heads/master), s/he can bypass reviews by pushing changes straight into the branch. This is very much by design and is necessary for common tasks like importing upstream commits. In many cases this action is restricted to administrators, project maintainers, and similar power users in order to enforce reviews, but I'm sure some organizations use Gerrit for optional code reviews. Gerrit should be regarded as a general purpose Git server that supports code reviews.

If you don't want this behavior then you should adjust the access rights of your gits.