Git Cherry-Pick會創建斑點嗎？

Question

幾個月前又增加了一項功能。 該功能是在三個單獨的提交中引入的。 為了恢復功能，我想將這三個提交git cherry-pick到一個分支（rel060）上，該分支是從commits合並到生產之前的最后一個標簽（release-0.6.0）創建的，由git describe指示。

完成后，我想將此操作的結果與當前生產頭上文件的內容進行比較。

git co -b rel060 release-0.6.0
git cherry-pick ead47f2
  [rel060 f28fed4] Corrects non-display of subtabs. (SITE-657)
  1 files changed, 5 insertions(+), 8 deletions(-)
git cherry-pick b22c4d4
  [rel060 b0014f1] Correct subtab bug in Firefox/IE. (SITE-657)
  1 files changed, 18 insertions(+), 24 deletions(-)
git cherry-pick ae5a321
  [rel060 5b41410] Corrects bug with subtab line collapse. (SITE-657)
  1 files changed, 5 insertions(+), 1 deletions(-)
git diff rel060:./cron_lp_functions.php..production:./cron_db_lpgenerate.php
  error: Object 2ce3dd45e32e1bef6da0b22a9ee7208c63e203d2 is a blob, not a commit
  error: Object f41574b41b82aba51876b5f7aba0d3ff9c6677c5 is a blob, not a commit
  fatal: Invalid revision range rel060:./cron_lp_functions.php..production:./cron_db_lpgenerate.php

出於價值，嘗試在cron_lp _...選項卡上自動完成選項產生了： Not a valid object name rel060:.

functions文件是一個文件，其內容隨后被lpgenerate 。

現在，我意識到可以做一百萬種比較簡單的選擇來做我想做的事情（將這三個提交看做是一個diff，diff標記將功能釋放到相關行的當前狀態）。

我想知道的是：為什么會出現特定錯誤？ 事實證明，摘櫻桃似乎對這個問題毫無幫助。 從標記創建分支后嘗試diff會產生相同的錯誤。 我錯過了git中的一些基本知識嗎？ 從發行版創建分支似乎是無害的...是否有一些我沒有想過的無害的陷阱？

Answer 1

這樣做的原因是git diff <commit>..<commit>僅是為了保持向后兼容性而存在，並且在語法上是“錯誤的”。

首先說git diff A..B是不合邏輯的。它只是偶然地因歷史原因而起作用，並且出於“它從一開始就這樣工作，不破壞向后兼容性”的原因，我們一直在運作。

但是，最好不要學習它，以在以新用戶身份學習git時保持理智。

點符號大約是一個范圍。 A..B談論的是B的祖先而不是A的祖先的一組提交。

 $ git log A..B 

顯示這樣一個范圍非常有意義。

但是“ diff”是關於“比較兩個端點”。 這樣的比較沒有“范圍”。 當您比較A和B的狀態時，您甚至都看不到它們之間的任何東西。 這就是為什么規范的說法是

 $ git diff AB 

並不是

 $ git diff A..B ;# WRONG. DO NOT DO THIS. 

和：是一種在記錄的樹中命名實體的方法。 通常，您使用這種語法命名blob，而不是表示子目錄的樹。

現在，當B1和B2是blob（或任何非提交式的東西）時，B1..B2即使在范圍上也沒有意義，並且這樣的請求在語法級別被檢測為錯誤（即，沒有開始“比較”）。

 $ git diff HEAD:Makefile..HEAD~4:Makefile ;# WRONG. DO NOT DO THIS. 

如果要比較兩個斑點，則可以使用規范的“比較兩件事”語法進行比較。

 $ git diff HEAD:Makefile HEAD~4:Makefile 

Junio C. Hamano的回答，通過git@vger.kernel.org