我试图将Gerrit关系链拆分为独立的提交,因为它们的更改位于项目的不同部分。
main -- A -- B
main -- A
\__ B
我不知道该用什么命令,所以我试着在main的tip上的一个新的git repo中用相同的Change ID推送Commit B(即git reset --hard origin/main
)。在Commit B的审查中,关系链中没有Commit A(预期的),但是Commit A的审查仍然显示Commit B在它的链中,并且显示“Not Current”,所以这可能不是正确的方法。
如何解决这个问题,使提交A的关系链不显示提交B?
2条答案
按热度按时间l2osamch1#
您可以尝试挑选更改,最简单的方法是使用下载命令。这将导致类似如下的结果:
这里我假设A =变化9642和B = 9643
rur96b6h2#
你做得对,变更A和变更B之间确实还有关系!
当你发送B rebased on
origin/main
的提交并将其发送回Gerrit时,它会检查接收到的提交是否存在具有相同(project, branch, Change-Id)
的预先存在的更改。如果存在,Gerrit会将你的新提交作为新补丁集附加到同一个更改。再次查看您的示例,但这次将补丁程序集编号附加到更改
A
和B
,您已经从以下内容开始:在Web UI中查看****
A
或B
时,可以看到关系链:然后在本地将B重定基到
main
上,您的本地存储库具有:当发送
B (rebased)
时,Gerrit将其作为第二个补丁集附加到B
的更改中。查看A时,Web UI显示:
这是因为
A
仍有后续更改,即补丁程序集B,1。当转到
B,2
时,您将不会再看到与A
的关系,因为您已将其重定基。一旦
B,2
被合并,Gerrit就会检测到它,当查看A
时,我认为它会显示:您可以修改
A
并将其发回复查。这将创建一个新的补丁程序集,该补丁程序集未附加到B
。在Gerrit端,资料档案库将如下所示: