2

数か月前に追加された機能にリグレッションがありました。この機能は、3つの別々のコミットで導入されました。機能を復元するためにgit cherry-pick、コミットが本番環境にマージされる前に作成された最後のタグ（release-0.6.0）から作成されたブランチ（rel060）に3つのコミットを行いました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。

今、私がやりたいことを実行するためのより簡単な選択肢が何百万もあることに気付きました（3つのコミットを1つの差分として参照し、タグを差分して、問題の行の現在の状態に機能を解放します）。

私が知りたいのはこれです：なぜ私は特定のエラーを受け取ったのですか？結局のところ、さくらんぼ狩りは問題とは何の関係もないようです。タグからブランチを作成した後にdiffを実行しようとすると、同じエラーが発生します。gitの基本的な何かを見逃したことがありますか？リリースからブランチを作成することは無害に思えます...私が取り上げていない無害な落とし穴はありますか？

4

1 に答える 1

2

この理由は、git diff <commit>..<commit>下位互換性を維持するためだけに存在し、構文的には「間違っています」。

git diff A..B "は、そもそも非論理的なことです。これは、歴史的な偶然によってのみ機能します。そのため、「最初からこのように機能していたため、下位互換性を壊さないでください」という理由で、それを機能させ続けています。

ただし、新しいユーザーとしてgitを学習するときは、正気を保つために、学習をやめたほうがよいでしょう。

ドット表記は範囲に関するものです。A..Bは、Bの祖先であるが、Aの祖先ではない一連のコミットについて話します。

$ git log A..B

そのような範囲を示すのは完全に理にかなっています。

しかし、「diff」は「2つのエンドポイントを比較する」ことです。そのような比較には「範囲」はありません。AとBの状態を比較すると、その間の状態すら見ていません。だからこそ、それを言うための標準的な方法は

$ git diff A B

ではなく

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

そして：は、に記録されたツリー内のエンティティに名前を付ける方法です。通常、この構文では、サブディレクトリを表すツリーではなく、blobに名前を付けます。

さて、B1とB2がブロブ（またはコミットっぽくないもの）である場合、B1..B2は範囲としても意味がなく、そのような要求は構文レベルでエラーとして検出されます（つまり、 「比較」を開始します）。

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

2つのBLOBを比較する場合は、正規の「2つのものを比較する」構文を使用して比較できます。

$ git diff HEAD:Makefile HEAD~4:Makefile

git@vger.kernel.org経由のJunioC.Hamanoからの回答

于 2012-10-09T21:18:00.947 に答える