2012-02-27 53 views
2

Gerrit將合併可能未提交的更改,這些更改早於提交歷史記錄並位於存儲庫的另一個「分支」中。這裏有一個例子:有沒有辦法強制Gerrit將分支中的所有提交推送到代碼審查?

  1. 結賬格里特分支devel
  2. 創建FILE1.TXT,添加,提交,推到refs/heads/temp_branch
  3. 創建FILE2.TXT,添加,提交,推到refs/for/devel是代碼審查

當file2.txt被接受併合並,然後file1.txt,因爲它在上游,而不是在一個單獨的更改分支被標記爲正在審查,也被合併。這可能是非常有問題的,唯一的解決方案,我可以來是與強制將每一項變更推送到每個分支進行代碼審查。這並不理想,因爲您可能希望擁有一組批准人的分支機構,或者沒有代碼審查(用於某些代碼交換?)。

這裏的解決方案是強制將歷史記錄中的每一個提交放入代碼審查中,就像file1.txt沒有被推送到同一個存儲庫中的不同分支一樣。

在Gerrit中是否存在強加此規則的設置? 任何人都可以想到一個工作流程,允許自由推進到refs/heads/而不會冒着污染其他分支的風險嗎?

非常感謝。

+0

我想在你的例子中,第2步真的是推/ ref/temp_branch? – Brad 2012-02-28 15:53:12

回答

2

我懷疑你看到了這種行爲,因爲步驟3中的提交將步驟2的提交作爲其父項。除非所有父母都已提交,否則您不能提交提交。我同意你的看法,這似乎是Gerrit中的一個錯誤 - 它應該拒絕提交,直到提交第2步。

嘗試此變通辦法 - 在步驟2後添加步驟2a:

2a。再次簽出devel分支

如果提交將轉到2個不同的分支,那麼它們對於它們是線性的沒有意義。

另一個想法 - 你在這個項目中使用了什麼合併策略?如果是櫻桃選擇,我會嘗試將它改爲合併 - 如果需要,或者如果它不是櫻桃選擇,我會嘗試將它改爲櫻桃選擇。我相信這裏的行爲在合併策略之間是不同的。

+0

原來,這個漏洞已在[Gerrit網站]上註明(http://code.google.com/p/gerrit/issues/detail?id=1107&sort=priority&colspec=ID%20Type%20Stars%20Milestone%20Status% 20Priority%20Owner%20Summary)。雖然你對櫻桃採摘是正確的!我不確定我是否相信合併衝突可能會導致櫻桃挑選,而這種衝突可能伴隨着通過代碼審查進行的多重鏈接變更,並且通常會保留提交歷史記錄的完整性。但它確實解決了無意合併未經審查的更改的問題。 – mut1na 2012-02-28 22:02:01

+0

只是爲了添加,櫻桃採摘本質上是在原始提交'官方'提交id時,它合併英寸也意味着你必須改變你的原產地分支爲自己的變化(雖然這將是微不足道的 - 即沒有衝突,因爲你已經有了代碼!),所以你的分支不會偏離原點。 – mut1na 2012-02-28 22:24:03

相關問題