为什么Gerrit接受推动，它无法处理？ [英] Why Gerrit is accepting pushes, it can't handle?

问题描述

遵循此回答以及Gerrit文档的相关信息。如果添加适当的引用是必需的：

  git push gerrit HEAD：refs / for / master 
  git push origin master 后，如果缺少适当的ref，push会被关闭（在Git级别），但不会创建更改（在Gerrit级别）。用户最终会在代码审查系统中混乱（无法合并不存在的更改，因为他或她没有更改而拒绝其他任何操作），并且必须执行很多奇怪的事情来解决这个问题。
 
 
 
什么是实施某项功能的理由或逻辑是否会被接受？为什么Gerrit不拒绝推送，它根本无法处理？
解决方案
您可以在Gerrit中创建推送规则管理页面，您可以在其中禁用直接推送。请参阅此处 
我的团队有两个不同的推送规则组是有用的。在同一分支上工作的小组，但只有一个小组介绍了Gerrit工作流程。但这并不意味着提交或更改会因为以不同方式推送到远程Barnch而导致混乱。 Gerrit / Git将通过拒绝非快速更改来处理它。
 
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?
解决方案
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.

                        
这篇关于为什么Gerrit接受推动，它无法处理？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！