我在使用Gerrit时犯了一个致命的错误,我想知道是否有人能提供一个解决方案/想法:
目前的情况是我有一个分支feature-foo
,我们的团队正在将变更推送到该分支上以供审阅。其中一些变更已经提交/合并,还有大量的变更仍在开放以供审阅。现在,昨天我决定将一个补丁集推送到一个特定的变更,该变更有大约15个先前的变更(尚未合并)。
我不小心跳过了代码评审(是的,我确实有这些权限,是的,我很愚蠢,为了我自己的安全没有停用它们--吸取了教训)。这导致了这15个更改/提交被直接推到分支上,而不是代码评审中。所以现在所有这些更改都在Gerrit中标记为MERGED
。我的第一个想法是使用我知道的最初是feature-foo
提示的提交来执行push -f
。
这正确地重置分支到它应该在的地方。但是-这15个变化仍然标记为MERGED
在Gerrit。我想要什么:我需要这些更改回到状态“审查进行中”,因为他们实际上仍在工作。
有什么想法吗?我无法想象这种事以前没发生过...
敬祝商祺,
--曲
编辑1:澄清一下-错误推送的提交导致了快进-而不是合并。然而,对于Gerrit来说,这些修改/提交仍然是“合并”的,就像有人在Gerrit的Web界面中按下了“提交修改”。所以-这个问题实际上是关于Gerrit的,而不是Git本身。
关键词:意外推送,意外合并
4条答案
按热度按时间anauzrmj1#
针对Gerrit 3+的更新(使用NoteDB):
当提交一个变更(或者仅仅是推送它)时,Gerrit会为变更创建一个新的补丁集,它带有一个“merged”属性。
对于变更集12345,你需要查看git的历史记录refs/changes/45/12345/ meta,这个“分支”包含了对变更集的讨论。
通过将该分支重置为提交之前的最后一次提交(提交应该具有类似于“创建补丁集2”的消息,具有属性“状态:merged”-取其父项),您将删除所有关于变更已被合并的知识。
您 * 可能 * 也必须刷新缓存--我刚刚在SSH接口上执行了“gerrit flush-caches --all”以确保这一点。
mm9b1k5b2#
我知道的唯一方法是使用新的
Change-Id
再次推送它。这将导致打开一个新的更改。c90pui9n3#
好吧,事实证明,这确实起到了作用:
1.将分支重置到它应该在的位置(强制推送过去的代码评审)
1.关闭Gerrit,访问底层H2数据库,并将所有受影响的变更ID的状态重置为“正在进行评审”(标准SQL,在WHERE子句中使用项目名称、分支名称和变更ID)。
svujldwt4#
我遇到了一些问题,我基本上不得不对已经在gerrit中合并100个提交进行重定基。
受“帕特里克·格奥尔基”的启发,我通过以下步骤让这个方法对我起作用:
注意:在我的例子中,
refs/changes/xx/yy/meta
不存在,但它们在gerrit服务器项目的/path/to/PROJECT.git/packed-refs
文件中。1.查询当前所有参考:
refs/changes/xx/yy
并将其保存到临时文件输出示例
1.将ref中的最后一位数字替换为
meta
输出示例
1.将
/tmp/CHANGES_NUMBERS2
复制到gerrit服务器1.**重要信息!!停止gerrit示例并
cd
**到项目的.git
目录确保
git log refs/changes/xx/yy/meta
返回日志!1.将
packed-refs
文件备份到安全的位置1.将来自
/tmp/CHANGES_NUMBERS2
的所有匹配引用的提交哈希替换为refs/changes/xx/yy/meta~1