git - 無視する git-diff ^M

Question

一部のファイルに改行セパレータとして ^M が含まれているプロジェクト。git-diff はファイル全体が単なる 1 行であると見なすため、これらのファイルの差分を取ることは明らかに不可能です。

以前のバージョンとどのように違いますか?

「差分時に ^M を改行として扱う」のようなオプションはありますか?

prompt> git-diff "HEAD^" -- MyFile.as 
diff --git a/myproject/MyFile.as b/myproject/MyFile.as
index be78321..a393ba3 100644
--- a/myproject/MyFile.cpp
+++ b/myproject/MyFile.cpp
@@ -1 +1 @@
-<U+FEFF>import flash.events.MouseEvent;^Mimport mx.controls.*;^Mimport mx.utils.Delegate
\ No newline at end of file
+<U+FEFF>import flash.events.MouseEvent;^Mimport mx.controls.*;^Mimport mx.utils.Delegate
\ No newline at end of file
prompt>

アップデート：

これで、最新の 10 個のリビジョンをチェックアウトして CR を LF に変換する Ruby スクリプトを作成できました。

require 'fileutils'

if ARGV.size != 3
  puts "a git-path must be provided"
  puts "a filename must be provided"
  puts "a result-dir must be provided"
  puts "example:"
  puts "ruby gitcrdiff.rb project/dir1/dir2/dir3/ SomeFile.cpp tmp_somefile"
  exit(1)
end

gitpath = ARGV[0]
filename = ARGV[1]
resultdir = ARGV[2]

unless FileTest.exist?(".git")
  puts "this command must be run in the same dir as where .git resides"
  exit(1)
end

if FileTest.exist?(resultdir)
  puts "the result dir must not exist"
  exit(1)
end
FileUtils.mkdir(resultdir)

10.times do |i|
  revision = "^" * i
  cmd = "git show HEAD#{revision}:#{gitpath}#{filename} | tr '\\r' '\\n' > #{resultdir}/#{filename}_rev#{i}"
  puts cmd 
  system cmd
end

score 479 · Accepted Answer

GitHub は、git で処理されるリポジトリでは \n のみを改行文字として使用するようにすることを提案しています。自動変換するオプションがあります：

$ git config --global core.autocrlf true

もちろん、これはcrlfをlfに変換すると言われていますが、crをlfに変換したいのです。これがまだ機能することを願っています…</p>

次に、ファイルを変換します。

# Remove everything from the index
$ git rm --cached -r .

# Re-add all the deleted files to the index
# You should get lots of messages like: "warning: CRLF will be replaced by LF in <file>."
$ git diff --cached --name-only -z | xargs -0 git add

# Commit
$ git commit -m "Fix CRLF"

core.autocrlf はman ページに記載されています。

score 432 · Accepted Answer

Windows で開発しているときに、を使用しているときにこの問題に遭遇しましたgit tfs。私はこのように解決しました：

git config --global core.whitespace cr-at-eol

これは基本的に、行末 CR がエラーではないことを Git に伝えます。その結果、これらの煩わしい文字は、、など^Mの行末に表示されなくなりました。git diffgit show

他の設定はそのままのようです。たとえば、行末の余分なスペースは引き続き差分にエラーとして表示されます (赤色で強調表示)。

（他の回答はこれをほのめかしていますが、上記は設定を設定する方法です。1つのプロジェクトのみに設定を設定するには、を省略し--globalます。）

編集：

多くの行末の苦労の後、.NET チームで作業しているときに、次の設定で最高の幸運が得られました。

core.eol 設定なし
core.whitespace 設定なし
core.autocrlf 設定なし
Windows 用の Git インストーラーを実行すると、次の 3 つのオプションが表示されます。
- Windows スタイルのチェックアウト、Unix スタイルの行末のコミット <-- これを選択
- そのままチェックアウトし、Unix スタイルの行末をコミットします
- そのままチェックアウト、そのままコミット

空白設定を使用する必要がある場合、TFS と対話する必要がある場合は、おそらくプロジェクトごとにのみ有効にする必要があります。を省略して--globalください:

git config core.whitespace cr-at-eol

一部の core.* 設定を削除する必要がある場合、最も簡単な方法は次のコマンドを実行することです。

git config --global -e

これにより、グローバル .gitconfig ファイルがテキストエディターで開き、削除する行を簡単に削除できます。(または、それらの前に「#」を付けてコメントアウトすることもできます。)

score 155 · Accepted Answer

git diff --ignore-space-at-eol、またはgit diff --ignore-space-change、またはを試してくださいgit diff --ignore-all-space。

score 111 · Accepted Answer

以下も参照してください。

core.whitespace = cr-at-eol

または同等に、

[core]
    whitespace = cr-at-eol

whitespaceの前にタブ文字があります。

score 52 · Accepted Answer

なぜあなたはこれら`^M`をあなたの中に入れます`git diff`か？

私の場合、Windows で開発されたプロジェクトに取り組んでおり、Linux を使用していました。いくつかのコードを変更したとき、^M追加した行の最後にgit diff. ^Mファイルの残りの部分とは行末が異なっていたため、表示されていたと思います。ファイルの残りの部分は Windows で開発されたため、CRLF行末を使用し、Linux ではLF行末を使用しています。

どうやら、Windows 開発者は、Git のインストール中に「Windows スタイルをチェックアウトし、Unix スタイルの行末をコミットする」オプションを使用しなかったようです。

では、これについて何をすべきでしょうか？

Windows ユーザーに git を再インストールしてもらい、「Windows スタイルをチェックアウトし、Unix スタイルの行末をコミットする」オプションを使用することができます。Windows は行末文字の例外と見なされ、Windows はこの方法で独自の問題を修正するので、これが私が好むことです。

ただし、このオプションを使用する場合は、現在のファイルを修正する必要があります (まだCRLF行末を使用しているため)。次の手順に従ってこれを行いました。

ファイルシステムからではなく、リポジトリからすべてのファイルを削除します。
```
 git rm --cached -r .
```
特定のファイルが aを行末として.gitattributes使用するように強制するファイルを追加します。LFこれをファイルに入れてください：
```
 * text=auto eol=lf
```

すべてのファイルを再度追加します。

 git add .

これにより、次のようなメッセージが表示されます。

 warning: CRLF will be replaced by LF in <filename>.
 The file will have its original line endings in your working directory.

「 Windows スタイルをチェックアウトし、Unix スタイルの行末をコミットする」オプション.gitattributesを使用したくない頑固な Windows ユーザーがいない限り、ファイルを削除できます。
すべてをコミットしてプッシュします。
それらが使用されているすべてのシステムで、該当するファイルを削除してチェックアウトします。Windows システムでは、「Windows スタイルのチェックアウト、Unix スタイルの行末をコミットする」オプションが使用されていることを確認してください。ファイルを追加したときにgitが言ったので、これらのタスクを実行したシステムでもこれを行う必要があります。
```
 The file will have its original line endings in your working directory.
```
ファイルを削除するには、次のようにします。
```
 git ls | grep ".ext$" | xargs rm -f
```
そして、これは正しい行末でそれらを取り戻すために：
```
 git ls | grep ".ext$" | xargs git checkout
```
.ext一致させたいファイル拡張子に置き換えます。

これで、プロジェクトLFは行末に文字のみを使用し、厄介なCR文字が戻ってくることはありません:)。

もう 1 つのオプションは、Windows スタイルの行末を強制することです。.gitattributesこのファイルを使用することもできます。

詳細: https://help.github.com/articles/dealing-with-line-endings/#platform-all

score 36 · Accepted Answer

TL;DR

ソースコードではなく、に変更しcore.pagerます"tr -d '\r' | less -REX"

これが理由です

表示されているこれらの厄介な ^M は、カラー化とページャーのアーティファクトです。これは、デフォルトの git ページャーオプションであるが原因です。less -R(git のデフォルトのページャーはless -REX)

最初に注意すべきことは、git diff -b空白の変更が表示されないことです (例: \r\n と \n)

設定：

git clone https://github.com/CipherShed/CipherShed
cd CipherShed

UNIX ファイルを作成して行末を変更する簡単なテストでは、次のように変更が表示されませんgit diff -b。

echo -e 'The quick brown fox\njumped over the lazy\ndogs.' > test.txt
git add test.txt
unix2dos.exe test.txt
git diff -b test.txt

パイプをlessに強制しても^Mは表示されませんが、色を有効にすると表示されることに注意してくださいless -R。

git diff origin/v0.7.4.0 origin/v0.7.4.1 | less
git -c color.ui=always diff origin/v0.7.4.0 origin/v0.7.4.1 | less -R

パイプを使用して \r (^M) を出力から削除することで、修正が示されます。

git diff origin/v0.7.4.0 origin/v0.7.4.1
git -c core.pager="tr -d '\r' | less -REX"  diff origin/v0.7.4.0 origin/v0.7.4.1

less -r色コードだけでなく、すべての制御コードを通過するため、賢明な代替手段はを使用することです。

git 構成ファイルを直接編集するだけの場合は、これが更新/追加するエントリです。

[core]
        pager = tr -d '\\r' | less -REX

score 0 · Accepted Answer

git diffを作成するが異なるエンディングを表示しない簡単な行が必要な場合（したがって、 ^M）は、元の質問の最初のコメントにあるものを使用します。それは私にとってはうまくいきました：

 git diff -b

他のすべての回答が示唆するように、長期的には、行末の設定を正しく行う必要があることを考慮してください。

git - 無視する git-diff ^M

11 に答える 11

なぜあなたはこれら^Mをあなたの中に入れますgit diffか？

では、これについて何をすべきでしょうか？

Related

Reference

なぜあなたはこれら`^M`をあなたの中に入れます`git diff`か？