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