このgitコマンドのファイル名の前にある二重ダッシュの意味は何ですか?
git checkout --ours -- path/to/file.txt
git checkout --theirs -- path/to/file.txt
それらは必須ですか?と同等ですか
git checkout --ours path/to/file.txt
git checkout --theirs path/to/file.txt
このgitコマンドのファイル名の前にある二重ダッシュの意味は何ですか?
git checkout --ours -- path/to/file.txt
git checkout --theirs -- path/to/file.txt
それらは必須ですか?と同等ですか
git checkout --ours path/to/file.txt
git checkout --theirs path/to/file.txt
Gitリポジトリに名前の付いたファイルがあり、そのファイルのpath/to/file.txt
変更を元に戻したいとします。
git checkout path/to/file.txt
ここで、ファイルの名前がmaster
...であるとします。
git checkout master
おっと!代わりにブランチを変更しました。チェックアウトするツリーを、--
チェックアウトするファイルから分離します。
git checkout -- master
また、一部のフリーコが-f
リポジトリに名前の付いたファイルを追加した場合にも役立ちます。
git checkout -f # wrong
git checkout -- -f # right
これは、git-checkout:ArgumentDisambiguationに記載されています。
二重ダッシュ「-」は「コマンドラインフラグの終了」を意味します。つまり、コマンドラインオプションの後に続くものを解析しようとしないように前のコマンドに指示します。
--
引数にワイルドカード(*
) が含まれている場合、Git 2.5(2015年第2四半期)a''なので、必要ないことに注意してください。
git <cmd> <revs> <pathspec>
誤って入力されたパスをキャッチするための""コマンドライン規則を支援するヒューリスティックは、コマンドラインの後半にあるすべての非revパラメーターが作業ツリー内のファイルの名前であることを確認することですが、これgit grep $str -- \*.c
は常に""でなければならないことを意味します。 ""で明確にされ--
たのは、文字通り名前がasterisk-dot-seeであるファイルを誰も正気に作成しないためです。
Git 2.5はヒューリスティックを失い、ワイルドカード文字列を使用して、ユーザーがパススペックを提供することを意図している可能性が高いことを宣言します。
git checkout 'a*'
# same as
git checkout -- 'a*'
Duy Nguyen()によるcommit 28fcc0b(2015年5月2日)を参照してください。(濱野純雄による合併---コミット949d167、 2015年5月19日)nguyenlocduy
gitster
pathspec
--
:ワイルドカードを使用する場合は、「」の必要性を回避してくださいコマンドラインに「
--
」がなく、コマンドが回転数とパスの両方を取得できる場合、引数が拡張SHA-1とパスの両方と見なされる場合は、「--
」が必要であるか、gitが続行を拒否します。
現在、次のように実装されています。
- (1)引数がrevの場合、それはワークツリーに存在してはなりません
- (2)それ以外の場合は、ワークツリーに存在する必要があります
- (3)それ以外の場合は、「
--
」が必要です。これらのルールはリテラルパスに対して機能しますが、非リテラルpathspecが含ま
--
れる場合、(2)に失敗し、(1)が実際に満たされることはめったにないため、ほとんどの場合、ユーザーは ""を追加する必要があります(*.c
たとえば、(1) ""という名前の参照がある場合に満たされ*.c
ます)。このパッチは、有効な(
*
)ワイルドカードパススペックが「ワークツリーに存在する」ことを考慮して、ルールを少し変更します。
ルールは次のようになります。
- (1)argがrevの場合、それはワークツリーに存在するか、有効なワイルドカードパススペックではない必要があります。
- (2)それ以外の場合は、ワークツリーに存在するか、ワイルドカードパススペックです
- (3)それ以外の場合は、「
--
」が必要です。新しいルールで
--
は、ワイルドカードパススペックが関係している場合、ほとんどの場合「」は必要ありません。
Git 2.26(2020年第1四半期)では、リビジョンとパススペックを区別するための曖昧性解消ロジックが調整され、バックスラッシュでエスケープされたグロブ特殊文字が「ワイルドカードはパススペック」ルールに含まれないようになりました。
Jeff King()によるcommit 39e21c6(2020年1月25日)を参照してください。( Junio C Hamanoによってマージされました---コミット341f8a6、2020年2月12日)peff
gitster
verify_filename()
:「ワイルドカードはパススペックです」ルールでバックスラッシュを処理します報告者:DavidBurström承認者
:Jeff Kingコミット28fcc0b71a(
pathspec
:ワイルドカードを使用する場合は ""の必要性を回避--
、2015-05-02)許可:git rev-parse '*.c'
ダブルダッシュなし。
ただし、ワイルドカードをチェックするために使用するルールは、実際にはグロブスペシャルを探します。
これは、「」のように実際にはワイルドカードの一致を行わないパターンがa\b
パススペックと見なされることを意味するため、過度に寛大です。あなたがディスク上にそのようなファイルを持っているなら、それはおそらくあなたが望んでいたものです。
しかし、そうでない場合、結果は混乱を招きます。「there's no such path a\b
」と言うのではなく、何にも一致しない(または少なくとも意図したものとは一致しない)パススペックとして静かに受け入れます。
同様に、パス "a\*b
"を検索しても、検索はまったく拡張されません。単一のエントリ"a*b
"のみが検索されます。このコミットにより、globメタ文字が検索を拡張する場合にのみトリガーするようにルールが切り替わります。つまり、どちらの場合もエラーが報告されるようになります(
--
もちろん、「」を使用して明確にすることができます。DWIMヒューリスティックを強化しているだけです)。
28fcc0b71aでは元の機能をまったくテストしていないことに注意してください。
したがって、このパッチは、これらのコーナーケースをテストするだけでなく、既存の動作の回帰テストも追加します。