如果还有第二个较新的评论,如何修改Gerrit中的评论问题

时间:2012-09-19 02:32:10

标签: git gerrit

仍在尝试学习如何使用Gerrit及其流程。我做的步骤

  1. 首先将change1推送到gerrit,以便审核到HEAD:refs / for / develop
  2. 在同一分支上处理其他内容并将change2推送到gerrit以便审核到HEAD:refs / for / develop
  3. 两个提交都有gerrit Change-ID行

    所以现在我想解决change1的问题所以我做了

    git checkout -b change1 <change 1's commit id>
    

    进行我的更改并提交(将更改ID添加到提交消息)

    git add .
    git commit
    

    现在我做的时候

    git push origin HEAD:refs/for/develop
    

    我得到了

     ! [remote rejected] HEAD -> refs/for/develop (squash commits first)
    error: failed to push some refs to 'ssh://adrian@192.168.7.100:29418/CommunicationsLibrary'
    

    如何解决堆叠评论中的问题并将其发布到gerrit而无需创建另一个评论?

6 个答案:

答案 0 :(得分:17)

如果您在Gerrit中有依赖性评论(也就是说,评论中的一项更改取决于同时审核的早期更改),并且您需要对之前的更改进行修改,则实际上必须重新提交这两项更改(因为第二次更改依赖于不同的“父”提交)

所以情况是你在主开发分支的一个分支中有两个提交,如下所示:

o master
\
 o Commit A (in review, requires change)
 o Commit B (in review, no changes required)

在这种情况下,我通常做的是在第三次提交中进行Commit A请求的更改。我们的提交图现在看起来像这样:

o master
\
 o Commit A (in review, requires change)
 o Commit B (in review, no changes required)
 o Commit C (modifications to Commit A)

现在我执行git rebase -i master并将Commit C重新排序在Commit A之后但在Commit B之前,然后将其压缩为Commit A.提交图现在看起来像这样:

o master
\ 
 o Commit A' (Commit A, incorporating the changes from Commit C)
 o Commit B' (the same changes made in Commit B, but applied to Commit A' instead of A)

最后,git review(或用于提交对gerrit的更改的任何命令)重新提交给Gerrit的两次提交。

由于这样的复杂性,大多数人强烈建议在单独的分支中处理每个不同的更改,然后在提交给Gerrit之前压缩到单个提交,而不是需要处理这些类型的情况正在同时审核变更。

答案 1 :(得分:2)

我认为你的问题与第一次提交的修正案现在将第二次提交作为依赖关系这一事实有关。这是我个人会做的,但可能有更好的方法。我看看它,因为你想改变你的提交方式,你正在处理最后的3.所以运行'git rebase -i HEAD~3'。这允许您通过切换顺序或将它们彼此融合来重新定义最后3次提交。您应该知道它以最早的顺序列出了提交。这是一个例子:

git log如下:

提交信息:......

消息:foo2

提交信息:......

消息:bar1

提交信息:......

消息:foo1

运行上述命令后,编辑器应弹出以下内容:

选择foo1。

选择bar1。

选择foo2。

(这假设您的第二个foo更改没有更改bar1更改的任何文件,因为这可能不起作用,如果您这样做了,您应该已经修改了提交。)然后将列表更改为:< / p>

选择foo1

fixup foo2

选择bar1

之后你将把foo1和foo2压缩成一个提交,bar1将是后面的提交。然后我会运行'git reset --soft HEAD~1'重置最新提交,然后是'git commit --amend',它允许你更改第一次审核的提交消息,并确保包含change-id 。然后尝试你的推动。之后,您应该设置一个新的补丁,第二次更改的所有文件将被修改并仍在您的工作目录中。

答案 2 :(得分:0)

呼叫

commit --ammend

代替你的第二次改变

答案 3 :(得分:0)

只需git commit --amend然后git review

答案 4 :(得分:0)

情况与@Trevor解释的完全一样。如果遇到这种情况,http://localhost:3000/emails是一个好方法。

我个人也使用此命令,但有一点不同:

1。使用--fixup和--autosquash

您有两次提交:

rebase -i

当您想更改旧提交时,然后

old commit
new commit

然后使用自动壁垒进行重新定位,

 git commit --fixup <old_commit_id>

如果不清楚我的评论,可以在以下位置查看详细信息: https://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html

OR

2。利用Gerrit

提交两次更改后,您的GUI上将发生两个打开审核更改。

然后转到您的“旧更改”,选择下载->结帐,实际上,在结帐后,您将转到此更改的分支,然后修复代码,修改,重新设置基础,像往常一样推动...。

答案 5 :(得分:-2)

我试过这些尝试

  1. 做了git rebase -i master
    它不起作用
  2. 然后我做了什么,我采取了文件的备份。删除了整个项目。然后再次克隆它。从备份粘贴所需文件夹中的文件,然后再次重新启动,然后按下。它奏效了。