'git cherry'是否考慮頭部和上游的提交次數？

考慮以下情形：'git cherry'是否考慮頭部和上游的提交次數？

$ git branch –a 
* dev 
    master 

$ git branch --contains 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6 
dev 

$ git branch --contains f7dfb3689edcaf5f819fa5e691ce13abf858bca8 
    dev 
    master 

$ git cherry master dev 
+ 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6 
+ a4e66dbde954f73185d61bfb78b40ac5e61fe56c 
+ 6fcffbd9b57e8a74726ea2cd3713f14baaaa06f5 
+ 5031ad3cdf2e81c880e9cbf049abed6f1edde3bc 
+ dcca33c373df6953ff164e8d70531abd71841278

但轉折是，提交f7dfb3689edcaf5f819fa5e691ce13abf858bca8實際上是櫻桃從53fdfaf89fca499c36c71d29f25eb1a13b32d4d6摘下來的，這兩個是完全一樣的（請原諒我，因爲出於某種原因，我們必須有2個完全相同的提交使用不同的提交ID）除了提交消息和提交ID之外，兩個提交之間沒有區別。

現在根據git cherry文檔， 提交進行比較，他們的補丁ID，從git patch-id程序獲得。

所以其實我去前進，執行git patch-id程序如下

$ git show 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6 | git patch-id 
bd6c061bd6c380d53832510cbaf68bebb4fb182d 53fdfaf89fca499c36c71d29f25eb1a13b32d4d6 

$ git show f7dfb3689edcaf5f819fa5e691ce13abf858bca8 | git patch-id 
bd6c061bd6c380d53832510cbaf68bebb4fb182d f7dfb3689edcaf5f819fa5e691ce13abf858bca8

上述結果表明：git patch-id實際上不會承認這兩個提交是相同的，但仍然是git cherry命令無法做到這一點。

我可以看到這種情況發生的唯一原因是git cherry考慮到git patch-id以外的因素。

它是否考慮頭部提交的數量（即我的情況下的開發分支）？由於我們在開發分支上有兩個版本的提交，而在主控上只有一個版本。

來源

2012-12-06 Sudha Rao

即使對於多個實例它也應該可以工作。只在本地進行了測試，確實能正常工作。 –

從上面的輸出中，您已將cherry-pick修訂合併到dev中（通過合併master在某處）。 Git正在瀏覽一組修訂版本，它現在會發現一個完全匹配，並將其從要修改的修訂集中移除，並且不會爲其生成修補程序標識。好消息是，git merge仍然認識到dev上的原始更改已經掌握在主內，並且不會嘗試重新應用該更改。

我認爲在大多數涉及櫻桃採摘的工作流程中，您絕不會將包含櫻桃採摘的分支合併回您的分支。你通常會做更類似的事情：將修復提交給master，然後櫻桃選擇一個穩定的分支。或者，就你的情況而言，將錯誤修復提交給master，然後將master合併到dev中。

您可以看到背後的代碼git cherryhere。記下修補程序ID生成here。尤其要注意comment on line 719。它會要求修改master而不是dev，這是因爲master被合併到dev中。所以沒有生成補丁ID。因此，它看起來像你的原始非櫻桃選擇的修訂沒有被帶到主。

你可能會認爲行爲是一個錯誤。但是，我認爲，修正它可能會有很大的性能影響。

來源

2012-12-09 11:14:41 jszakmeister

'git cherry'是否考慮頭部和上游的提交次數？

回答

相關問題