2012-07-03 3 views
9

git checkout --<dir_name(or)file_name>を使用して、特定のディレクトリまたはファイルのすべての変更を破棄します。私がそれを行うたびに、GITはリポジトリからディレクトリ(または)ファイルをチェックアウトします。- git checkoutのdry-runオプション

は、私は「だけで何が起こるかを教えてください。、変更内容を上書きしませんgit clean -n(または)git clean --dry-runと同様に

を?, GITを伝えることができるが方法です。

UPDATE: 私は実行する前に、git checkout --src/、私はファイルが上書きされますされているかを確認したいと思います。私はgit status src/を使用できることを知っています。しかし、git checkout -n --src/を持つことは素晴らしいことではないでしょうか?ユーザーのコマンドの変更はほとんどありません。

+0

私は混乱しているかもしれませんが、作業ツリーとインデックスの違いを尋ねるだけではありませんか?それらは 'git diff'で示されています。 –

+0

@TilmanVogel:ご存じのように、 'git clean'コマンドは、追跡されていないファイルを削除します。 'git clean -n'はファイルを削除しません。ファイルが削除されるのはどういうことかだけです。私はちょうど知りたがっています、git checkoutコマンドにそのようなオプションがありますか?ありがとう。 –

+0

さて、 'git help checkout'を見ると、簡単にこれを「いいえ」と答えることができます。その理由は、「git status」と「git diff」が一緒にすべての情報を提供しているからだと思います。私はまた、その意見のために 'git citool'が好きです。もちろん、索引以外のもので 'git checkout'を使用すると、ストーリーは異なるものになります。 –

答えて

3

あなたは

$ git checkout --patch -- <files> 

を実行することができ、それはあなたがその違いを「チェックアウト」するかどうかを各差分を求められます。プロンプトごとに「いいえ」と答えた場合は、それはそのままです。

+0

ニース。それは私がほしいと思うほとんどです。ありがとう。 –

+0

しかし、私はまだ気になっています。 'git checkout'が' git clean'のように '-n'オプションを持っていれば素晴らしいかもしれません。コンテンツではなくファイル名のリストを私たちに教えてください。とにかくありがとう。 –

1

回避策はありませんでしたか?git stash -ugit apply次にgit checkout

あなたが不満を持っている場合は、いつでも元に戻すことができます。

5

Git checkoutコマンドにdry-run(または類似の)オプションがありません。

git ls-files -dm -- src/ 

これは、削除または変更されたすべてのファイル、通常checkoutによって上書きされるファイルの一覧が表示されます。ただし、HEAD異なるた作業ディレクトリのファイルを見るためにGitのls-filesコマンドを使用することができます。

git diff --name-only HEAD -- src/ 

これはHEADとは異なり、checkoutに置き換えられるすべてのファイルを一覧表示します:

別のオプションは、Gitのdiffコマンドを使用することです。

その後
git config --global alias.lco "diff --name-only HEAD" 

あなたが使用することができます:これは頻繁に行われることになる何かがある場合は

、あなたはalias作成することもできます(

git lco -- src/ 
+0

Danさんに感謝します。それは非常に便利です。私はアップした:-) –

0

あなたが対話を避けたい場合はア・ラ"各プロンプトにnoと答えてください")、git diffを使用してください。あなたの質問に正確に答えるには、git diff -Rを使用してください。ファイル名だけが必要な場合は、git diff --name-onlyを使用してください。

-Rフラグがないと、git diffは作業ツリーとインデックスの相違点をすべてパッチ形式、つまりgit show <commit>を発行したときに表示される形式で報告します。 -Rは出力を元に戻し、変更が削除されたことを、削除自体がパッチであるかのように表示します。例を考えてみましょう:

git init /tmp/test && cd /tmp/test 
echo "old line">file 
git add . 
git commit -m "Initial commit" 
echo "new line">file 

は今どのフラグなしgit diffを発行します。あなたが得る必要があります。

$ git diff 
diff --git a/file b/file 
index 0906fba..86ba82a 100644 
--- a/file 
+++ b/file 
@@ -1 +1 @@ 
-old line 
+new line 

は、率直に言って、私は-Rフラグを使用することはありません解析するのは簡単その出力を見つけます。 git diffコマンドを日常的に発行している場合(そして私が使用する最も一般的なコマンドの1つであることがわかります)、逆の出力は必要ありません。すべて同じことが、この回答の目的のために、試してみてください。

$ git diff -R 
git diff -R 
diff --git b/file a/file 
index 86ba82a..0906fba 100644 
--- b/file 
+++ a/file 
@@ -1 +1 @@ 
-new line 
+old line 

出力は正確にあなたが求めるものを記述する:「変更を上書きしていない、ただ、何が起こるかを教えてください。」

デフォルトでは、このコマンドは作業ディレクトリ全体とインデックスを比較します。すべての変更されたファイルの差分を表示します。 1つのファイルにその効果を見たいとします。それは簡単です。ちょうどあなたがすでに使用している同じダブルダッシュ命名法を使用します。

git diff -- <file> 

Gitの中で最も有用な、拡張可能なコマンドのいずれかであることをgit diffを見つけることができます、そしてあなたが役に立つのすべてのソートを行うには、それを使用することができますもの。これを使用して、2つのコミット、2つのブランチ、または2つのファイルを比較できます。私の最近の「お気に入りのクレイジーギタリスト操作」はgit diffからgit applyへの配管です。前者はわかりやすいパッチを生成します。後者はそれらを適用します。それらが結合されたときに履歴を書き換えるあなたの能力は非常に無限です。ローカルではもちろん、は共有履歴を書き換えません。別の例を考えてみましょう。この時点では話題にはなりませんが、真剣に面白いです(あなたがこのようなことをしている場合)。私たちのテストレポジトリより上記:

git add . 
git commit -m "Second commit" 
echo "even newer line">file 
git add . 
git commit -m "Third commit" 

あなたは何を知っていますか?私はその第二のコミットがあまり好きではなかった。その実装はバグだった。それは破壊試験です。私はそれを共有したくない。それにもかかわらず、私は "Second commit"コミットメッセージを保持したいのですが、これは実際に入力するのが難しいためです。私はgit rebase -i HEAD~2でそれを再定義することができますが、それはエディタを開くこと、コミットを削除すること、別の(ugh)コピー/ペーストを編集することを伴う。開発者とは何ですか?どうですか:

git checkout ":/Initial" ;# get back to the first commit 
git diff HEAD ":/Third" | git apply ;# apply the diff between the first and third commit 
git add . ;# add the result 
git commit -C ":/Second" ;# with second commit's message 
git checkout -B master HEAD ;# and replace old 'master' 

結果はgit rebaseと同じです。私はちょうど対話セッションを避けることができたので、エディタを使う必要はありませんでした。それは過労ですか?おそらく、それは確かに楽しいです。さらに、特に、git diffgit apply、およびgit add -pを組み合わせると、はるかに複雑なユースケースを構築するのは簡単です。

1

コマンドのドライ・ラン・オプションを希望する場合は、「他の方法の違いのリストを得ることができるため、チェックアウトのためのドライ・ランは必要ありません」とは関係ありません。

ドライ・ラン・オプションで相違点のリストを取得したくない場合は、ドライ・ランで「Enterを押したときにどうなるでしょうか?あなたが本当にそれをする前に。違いがあります。あなたがしたことがすべてマニュアルを読んでいれば、あいまいさがあるかもしれないときに、あなたはプログラムの実際の/正確な振る舞いをテストしています。

私はrepoが '/'に基づいているという奇妙なプロジェクトを持っています。したがって、 '/.git'ディレクトリと '/.gitignore'と '/.gitmodules'ファイルがあります。 /.gitignoreおよび/。gitmodulesファイルはリポジトリ内で追跡されます。これは、開発者のユーザーがファイルを編集する権限を持っていても、gitがファイルを削除して再作成する権限を持っていないためです。 '/'自体に対する書き込み権限を持っています。 gitでファイルを編集しても問題はありませんが、gitはファイルをリンク解除できないというエラーが発生するため、削除して置き換えます。

git checkout master -- /.git*

およびその他を:私たちのレポの設定への変更、および開発者のためのいくつかの方向性を開発する過程で、道に沿って私は、このコマンドがどうなるかを知りたい、将来的にこの問題を取り除くために従ってくださいシェルグロブおよび/またはgitの自体が、最終的なファイル指定値を解釈する方法を見ての変更

git checkout master -- '/.git*'

などのような可能な変形、。私がシェルから '*'をエスケープすると、gitは '*'を展開しますか、それをリテラルとして扱いますか?展開すると '/.git/'ディレクトリが含まれますか?それを展開すると、 ''のように 'one-single-non-empty-character'を意味する正規表現の構文がありますか?正規表現や '?'シェルグロビングで?

私は、どのファイルが違うか分かりません。珍しいコマンドやコマンドのセットのベスト/シンプルバージョンを見つけるためにgitの正確な動作をテストしたいと思います。

このため、実際にはドライランが必要です。私はすでにどのファイルが違うかを知っています。この場合、MANYファイルは違うでしょうし、私はそれらのファイルを望んでいません。私はちょうど/.gitignoreと/.gitmodulesとほかには何も望みません。

この場合、コマンドラインで両方を明示的に指定するだけで、これを行うことができます。

git checkout master -- /.gitignore /.gitmodules

しかし、私は、自動的にそれらの両方を取得し、まだ理想的には、/.gitディレクトリが含まれません短いグロブ構文があるかどうかを確認したいです。そして、理想的には、私が取り除くことができる最も簡単な形式を試してみたいと思います。私はシェルを使用して派手で非常に具体的な拡張を行うことができると知っていますが、 '/ git *'のようなものがあれば、むしろ '/ git {i、m} *'より使いたいと思っています。

タスクは小さく、いくつかの簡単な答えがあります。どうかこの「git checkout --dry-run」を使わないでこの問題を解決する方法を教えてはいけません。あるいは、私がそれを知っていることがどれほど愚かであるか教えてください。私はすでに自分の仕事を終わらせるためのいくつかの方法を知っています。それはポイントではありません。ファイルを明示的にリストするだけでは便利ではなかったり、まったく別のタイプの問題であったりする可能性があるため、より多くのファイルや複雑なglobbingパターンを簡単に含めることができました。

ポイントは一般に、git checkoutを含む任意のコマンドに適用されます。プログラム自体の動作をテストするには、常にドライランオプションを使用します。マニュアルや--helpを読んでも、ドライランが答えた質問には答えません。

関連する問題