内容が同じでも、Gitステータスにファイルが変更されたと表示される


192

他の人からgitチェックアウトを受け取り、ステージングされていない変更をローカルリポジトリにコミットしようとしています。ただし、内容がまったく同じであっても、多くの(すべてではないにしても)ファイルが変更されたように見えます。

私はすでにcore.fileModefalseに設定しており、falseにも設定core.autocrlfしていますが、成功していません。

注目に値するのは、私が受け取ったGitリポジトリは、Linuxを使用しているときにWindowsを使用している誰かからのものであることです。

実際の変更をコミットするにはどうすればよいですか?

編集:の出力git config -l

user.name=Aron Rotteveel
user.email=<removed>
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=auto
color.ui=true
color.pager=true
color.branch.current=yellow reverse
color.branch.local=yellow
color.branch.remote=green
color.diff.meta=yellow bold
color.diff.frag=magenta bold
color.diff.old=red bold
color.diff.new=green bold
color.status.added=yellow
color.status.changed=green
color.status.untracked=cyan
core.pager=less -FRSX
core.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol
alias.co=checkout
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
core.autocrlf=false
remote.origin.url=<removed>
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*

更新:ランダムなサンプルファイルをいくつか追加しました。これらのファイルはプレーンテキストなので、含めるのが最も簡単です。

元のファイルは、https//gist.github.com/c3c5302430935155ef3dにあります。Hexdumpは確実にファイルが異なることを示していますが、これの原因と修正方法はわかりません。

ヘッドバージョン:

0000000: 4854 4d4c 2e53 6166 654f 626a 6563 740d  HTML.SafeObject.
0000010: 0a54 5950 453a 2062 6f6f 6c0d 0a56 4552  .TYPE: bool..VER
0000020: 5349 4f4e 3a20 332e 312e 310d 0a44 4546  SION: 3.1.1..DEF
0000030: 4155 4c54 3a20 6661 6c73 650d 0a2d 2d44  AULT: false..--D
0000040: 4553 4352 4950 5449 4f4e 2d2d 0d0a 3c70  ESCRIPTION--..<p
0000050: 3e0d 0a20 2020 2057 6865 7468 6572 206f  >..    Whether o
0000060: 7220 6e6f 7420 746f 2070 6572 6d69 7420  r not to permit 
0000070: 6f62 6a65 6374 2074 6167 7320 696e 2064  object tags in d
0000080: 6f63 756d 656e 7473 2c20 7769 7468 2061  ocuments, with a
0000090: 206e 756d 6265 7220 6f66 2065 7874 7261   number of extra
00000a0: 0d0a 2020 2020 7365 6375 7269 7479 2066  ..    security f
00000b0: 6561 7475 7265 7320 6164 6465 6420 746f  eatures added to
00000c0: 2070 7265 7665 6e74 2073 6372 6970 7420   prevent script 
00000d0: 6578 6563 7574 696f 6e2e 2054 6869 7320  execution. This 
00000e0: 6973 2073 696d 696c 6172 2074 6f0d 0a20  is similar to.. 
00000f0: 2020 2077 6861 7420 7765 6273 6974 6573     what websites
0000100: 206c 696b 6520 4d79 5370 6163 6520 646f   like MySpace do
0000110: 2074 6f20 6f62 6a65 6374 2074 6167 732e   to object tags.
0000120: 2020 596f 7520 7368 6f75 6c64 2061 6c73    You should als
0000130: 6f20 656e 6162 6c65 0d0a 2020 2020 254f  o enable..    %O
0000140: 7574 7075 742e 466c 6173 6843 6f6d 7061  utput.FlashCompa
0000150: 7420 696e 206f 7264 6572 2074 6f20 6765  t in order to ge
0000160: 6e65 7261 7465 2049 6e74 6572 6e65 7420  nerate Internet 
0000170: 4578 706c 6f72 6572 0d0a 2020 2020 636f  Explorer..    co
0000180: 6d70 6174 6962 696c 6974 7920 636f 6465  mpatibility code
0000190: 2066 6f72 2079 6f75 7220 6f62 6a65 6374   for your object
00001a0: 2074 6167 732e 0d0a 3c2f 703e 0d0a 2d2d   tags...</p>..--
00001b0: 2320 7669 6d3a 2065 7420 7377 3d34 2073  # vim: et sw=4 s
00001c0: 7473 3d34 0d0a                           ts=4..

コピーしたバージョン:

0000000: 4854 4d4c 2e53 6166 654f 626a 6563 740a  HTML.SafeObject.
0000010: 5459 5045 3a20 626f 6f6c 0a56 4552 5349  TYPE: bool.VERSI
0000020: 4f4e 3a20 332e 312e 310a 4445 4641 554c  ON: 3.1.1.DEFAUL
0000030: 543a 2066 616c 7365 0a2d 2d44 4553 4352  T: false.--DESCR
0000040: 4950 5449 4f4e 2d2d 0a3c 703e 0a20 2020  IPTION--.<p>.   
0000050: 2057 6865 7468 6572 206f 7220 6e6f 7420   Whether or not 
0000060: 746f 2070 6572 6d69 7420 6f62 6a65 6374  to permit object
0000070: 2074 6167 7320 696e 2064 6f63 756d 656e   tags in documen
0000080: 7473 2c20 7769 7468 2061 206e 756d 6265  ts, with a numbe
0000090: 7220 6f66 2065 7874 7261 0a20 2020 2073  r of extra.    s
00000a0: 6563 7572 6974 7920 6665 6174 7572 6573  ecurity features
00000b0: 2061 6464 6564 2074 6f20 7072 6576 656e   added to preven
00000c0: 7420 7363 7269 7074 2065 7865 6375 7469  t script executi
00000d0: 6f6e 2e20 5468 6973 2069 7320 7369 6d69  on. This is simi
00000e0: 6c61 7220 746f 0a20 2020 2077 6861 7420  lar to.    what 
00000f0: 7765 6273 6974 6573 206c 696b 6520 4d79  websites like My
0000100: 5370 6163 6520 646f 2074 6f20 6f62 6a65  Space do to obje
0000110: 6374 2074 6167 732e 2020 596f 7520 7368  ct tags.  You sh
0000120: 6f75 6c64 2061 6c73 6f20 656e 6162 6c65  ould also enable
0000130: 0a20 2020 2025 4f75 7470 7574 2e46 6c61  .    %Output.Fla
0000140: 7368 436f 6d70 6174 2069 6e20 6f72 6465  shCompat in orde
0000150: 7220 746f 2067 656e 6572 6174 6520 496e  r to generate In
0000160: 7465 726e 6574 2045 7870 6c6f 7265 720a  ternet Explorer.
0000170: 2020 2020 636f 6d70 6174 6962 696c 6974      compatibilit
0000180: 7920 636f 6465 2066 6f72 2079 6f75 7220  y code for your 
0000190: 6f62 6a65 6374 2074 6167 732e 0a3c 2f70  object tags..</p
00001a0: 3e0a 2d2d 2320 7669 6d3a 2065 7420 7377  >.--# vim: et sw
00001b0: 3d34 2073 7473 3d34 0a                   =4 sts=4.

1
core.filemode未設定またはに設定している場合true、出力は異なりますか?
Mark Longair、2011

役立つ情報の他の重要なビットは出力のあるgit --version
マークLongair

2
@AronRotteveel:簡単です。最初のファイルにはCRLFの行末(ウィンドウ)があり、2番目のファイルにはLF(Unix)があります
11:14にsehe

3
git 2.8(2016年3月)git ls-files --eolには、eolが関係しているかどうかをすばやく確認するためのが導入されています。以下の私の回答を
VonC

Windowsのユーザーは、この問題を解決するためにgit config --global core.autocrlf trueを実行できます。
Inyoka

回答:


62

更新:この質問のコメントに従って、問題は解決されました:

それは簡単です。最初のファイルにはCRLF行末(ウィンドウ)、2番目のLF(UNIX)があります。file(gitの\ USR \ binに利用可能)UTILは(があることを示しますfile a bのようなものを返信させていただきますa: ASCII text, with CRLF line terminators b: ASCII text

以下の元の答え:


表示する差分には、1つの異なる行は表示されませ。.git / config(またはそれ以上git config -l)を投稿できますか?

空白の無視が有効になっている可能性があります

無効にしてみてくださいcore.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol

また

git show HEAD:myfile|md5sum
md5sum myfile

ファイルが実際に異なることを確認するために使用できます。外部差分を使用することもできます

git show HEAD:myfile > /tmp/myfile.HEAD

diff -u myfile /tmp/myfile.HEAD

# or if you prefer an interactive tool like e.g.:
vim -d myfile /tmp/myfile.HEAD

奇妙なことは、両方のファイルのためのMD5SUMSが異なっているが、私は見つけることができないということであるANY空白の違いを。(私はこれが事実だと思いますが、私はそれを見ないだけです)。どんな助けでも大歓迎です。
Aron Rotteveel、

どこかに例をアップロードしてください(gist.github.comがこれに適しています)。私はそれが最終行の改行、バイトオーダーマーク、または一般的に非標準のUTF8エンコーディングであると思います。バイナリの差分を見xxdたりbdiff、実行したりすることもできます
11:14

先端をありがとう。xdd私にとっては初めてでした。素晴らしいツール!私は例で私の投稿を更新しました。
Aron Rotteveel

1
@AronRotteveel:簡単です。最初のファイルにはCRLF行末(ウィンドウ)、2番目のファイルにはLF(UNIX)があります。編集file utilのは(ということを示しますfile a bようなもの返信させていただきますa: ASCII text, with CRLF line terminators b: ASCII text
sehe

それらは実際にはVIMで^ Mと表示されるべきではありませんか?(私はそれを見ません)。明らかに、私はあなたを信じていますが、あなたがこれに実際に気づいた方法に本当に興味があります:)
Aron Rotteveel

134

私は次のstpesを使用してこの問題を解決しました

1)Gitのインデックスからすべてのファイルを削除します。

git rm --cached -r .

2)Gitインデックスを書き換えて、すべての新しい行末を取得します。

git reset --hard

手順2でローカルの変更が削除される場合があることに注意してください。解決策はgitサイトhttps://help.github.com/articles/dealing-with-line-endings/で説明されている手順の一部でした


私の場合、いくつかのファイルに大量のメモを作成してから、.gitフォルダーなしでリポジトリを新しいコンピューターにコピーしました。.gitパッケージが見つからないことに気付いたとき、戻ってそれを取得するには遅すぎました。それで私は:1.リポジトリ全体の新しいコピーをチェックアウトしました2.バニラファイルを私の変更を含むファイルで置き換えました3. OPの投稿のステップ1を実行しました:git rm --cached -r .4.これは私の変更(および置き換えられた他のファイル)をステージングしました)なので、ステージングを解除しました。この時点で、私のリポジトリは正常に戻りました。
cody

2
鮮やかさ。これをありがとう。
rupi

6
変更すると他の変更が失われるので注意してください。
Mohy Eldeen

repoフォルダーをWindowsからUbuntuにコピーして貼り付けた後、この問題が発生しました。ローカルの変更はありませんでしたが、何らかの理由で、gitはすべてのファイルが変更されたと考えました。このソリューションはこの問題を解決しました。
Linek

86

ファイルのモードを変更しましたか?私は自分のマシンでそれを行い、ローカルの開発マシンはすべてのファイルに777を与えましたが、リポジトリは755ですべてのファイルが変更されたことを示しました。私はそうしましたgit diff、そしてそれは古いモードと新しいモードが異なることを示しました。それが問題なら、git config core.filemode false
乾杯で簡単に無視できます


2
Windows 10 lxss(つまりUbuntu Bash)をWindowsファイルシステムのリポでLinuxのgitを使用して、私はそれが行末の問題だと思っていました。ファイルモードが異なる方法である可能性も考えられませんでした。
Matt L

これは、ローカルのO / SをUbuntuからWindowsに変更したときにうまくいきました。乾杯
マークバックネル2018

@MattLとその私は通常、Git Bashを使用してWin 10で開発していますが、今日はMacを.gitignore使用しているため、gitはファイルが変更されていないのに変更されたと考えていることがわかります。このMacでは、でgit config core.filemode応答しtrueます。私はそれをに変更しましたfalseが、それは助けにはなりませんでした。
ライアン

43

同じ問題がありました。win-> lin copyの後、すべてのファイルを変更しました。fromdos
使用して行末を修正 してから

git add -uv 

変更を追加します。
それは私が実際に変更した3つのファイル(それらのすべてではない)を追加しました。その後、gitステータスには3つの変更されたファイルのみが表示されます。git commit後、すべてがgit statusで問題ありません


2
ありがとう、これが私が必要としていたものでした。私はmd5sumを比較するという@seheの提案を使用して、ファイルが同一であることを確認しました(私の場合は同じでした)。その後、-uフラグを使用すると、変更されたファイルと実際の違いがないファイルが正しくフィルタリングされます。
STW 2014年

おかげで、役に立ちました。npm iプロジェクトのルートで実行した後、この問題が発生しました。どういうわけか、多くのファイルは異なる行末を取得していたため、この問題が発生していました。
サーバーKhalilov

これは私が期待していたことです...行った変更は残り、残りは取り消されました
Deepak


24

私の場合、ファイルの権限を変更した後、ファイルが変更されたように見えました。

gitに権限の変更を無視させるには、次のようにします。

# For the current repository
git config core.filemode false   

# Globally
git config --global core.filemode false

1
あなたの答えは私に多くの時間を節約しました。ありがとう!
Pavel_K

これを行った後、必要な変更をスタッシュ/ステージングし、権限が変更されたファイルをリセット/チェックアウトしてから、再度有効にすることをお勧めしますcore.filemode。:)
XtraSimplicity

あるラップトップから別のラップトップにファイルをコピーした後、この問題が発生しました。あなたの修正はそれを保存しました。ありがとう!
サム・

23

ただし、内容がまったく同じであっても、多くの(すべてではないにしても)ファイルが変更されたように見えます。

git 2.8(2016年3月)を使用すると、これらの変更がEOL関連であるかどうかをすばやく確認できます。

見る a7630bdコミットにより(2016年1月16日)をトルステン・Bögershausen( )tboegi
(合併によりJunio C浜野- gitster-05f1539コミットし、2016年2月3日)を

ls-files:eol診断を追加

クロスプラットフォーム環境で作業する場合、ユーザーはテキストファイルがリポジトリに正規化されて保存されているかどうか、および .gitattributes適切に設定があります。

Gitに、インデックスと作業ツリーの行末、および効果的なtext / eol属性を表示させることができます。

行末( " eolinfo")は次のように表示されます。

"-text"        binary (or with bare CR) file
"none"         text file without any EOL
"lf"           text file with LF
"crlf"         text file with CRLF
"mixed"        text file with mixed line endings.

有効なtext / eol属性は次のいずれかです。

"", "-text", "text", "text=auto", "text eol=lf", "text eol=crlf"

git ls-files --eol このような出力を与えます:

i/none   w/none   attr/text=auto      t/t5100/empty
i/-text  w/-text  attr/-text          t/test-binary-2.png
i/lf     w/lf     attr/text eol=lf    t/t5100/rfc2047-info-0007
i/lf     w/crlf   attr/text eol=crlf  doit.bat
i/mixed  w/mixed  attr/               locale/XX.po

インデックス( ' i')のデータと作業ツリー( 'wいるパスごと ')、有効な属性を示します。


これは問題を示していますが、修正はされていません。
Greeso

7

これは、Windowsで作成されたプロジェクトのクローンを作成しているときにLinuxで問題を修正した方法です。

Linuxでは、物事が適切に機能するために、次の設定が必要です。core.autocrlf= input

これは設定方法です:git config --global core.autocrlf input

次に、githubからプロジェクトを再度複製します。


これは、WindowsでVisual Studioを使用しているシナリオでうまくいきましたが、コマンドラインでWSLのコミットと追加のチェックを行っています。コマンドラインでは、すべてのファイルが変更されたと表示されていましたが、Visual Studioでは、変更されたファイルはわずかです。.gitconfigファイルにautoclrf = inputを追加し、それを即座に修正しました。ありがとうございました!
ビッグデータブライアン

5

Gitのよくある質問は、私はこの前に遭遇したことはありませんが、関連するかもしれない答えを持っています:

git diffが変更のないファイルをリストすることがあるのはなぜですか?

git diffやその他のgit操作は最適化されているため、ディスクとgitのインデックスのステータス(サイズ、変更時刻など)が異なるファイルも参照されません。これにより、小さな変更に対してgit diffが非常に高速になります。ファイルがなんらかの方法で変更された場合、git diffは内容を確認して比較する必要があります。これは、実際に変更がない場合でも、処理がはるかに遅くなります。git diffは、ファイルが最適に使用されていないことを思い出させるものとしてファイルをリストします。git statusを実行すると、ステータスが表示されるだけでなく、変更されていないファイルのステータスでインデックスが更新され、diffだけでなく、後続の操作がはるかに高速になります。多くのファイルがdiffによって一覧表示される典型的なケースは、perl -pi -e '...'のような一括編集コマンドを実行することです。

なに git status示していますか?


git status変更されたセクションにファイルの膨大なリストを表示するだけです。
Aron Rotteveel

@Aron:私が言うその手がかりに基づいて:85%がラインエンドコンバージョンを言う
sehe

4
ワオ。公式のgitドキュメントの一部がどれほどわかりにくいかを思い出させます。
火星

2

ローカルレポジトリと作業コピーを別のフォルダー(Windowsではちなみに)にコピーした後、4つのファイルが変更されて表示され続け、他の回答に記載されているすべての提案を試しました。結局、私にとってそれを修正したのは、ローカルブランチを削除し、リモートから再度ダウンロードすることでした。私の場合、それはクローンではなくローカルリポジトリのコピーに関係していると思います。


2

だから、私はここですべてを試してみて、私の問題のすべてを修正したもう1つのソリューションに貢献したいと思います。私の問題は、行末や実際のアクセス許可などではありませんでした。それは私がCygwinとそれに付随するもののホスト全体をインストールしたためでした。それは私には知られていないもので、独自のバージョンのgitもインストールしました。私はこれに気づきませんでした。(permsの変更のために)ユーザーとファイルが変更済みとしてマークされているという奇妙な問題があっただけです。

Gitを最新バージョンに更新するだけでよいと思ったのですが、実行git --versionすると古いバージョン番号が返されました。その後の理由の調査の後、古いバージョン番号で実行されているgit実行可能ファイルを含む環境パスにcygwin binディレクトリルートが見つかりました。図を行きます。

TortoiseGitがインストールされているため、これも見つけるのが困難でした。私のコマンドラインツールはパスのフォールバックのためにcygwinバージョンを使用し、TortoiseGitはWindowsバージョンを使用するように構成されていたため、さらに混乱しました。

これが誰かを助けることを願っています。


1
良いキャッチ。+1。そのため、私は常に自分でPATHを設定しています。例:stackoverflow.com/a/44351065/6309
VonC

私はしばしばインストーラーにPATHを設定させますが、それをここで手動で確認しました。以前のインストールにはgit 2.4.x(x86)があり、git 2.13.x(x64)をインストールしました。x86パス参照を削除しても2.4になったときの混乱を想像できます。それは私がcygwinのbinディレクトリを見たときであり、それは次に見るべき論理的な場所のように思われました。したがって、Cygwin binディレクトリーが最初にリストされている場合、FWIW設定またはPATHを視覚的にチェックすることでこれを解決できない可能性があります。
dudewad 2017

1

あなたの設定の唯一の疑わしいエントリは私に見えますcore.ignorecase。あなたはそれを解除することを試みることができます:

  git config --unset core.ignorecase

...からの出力が異なるgit statusかどうかを確認しますgit diff



0

私にとっては、2つのLinux VMが両方とも同じホームファイルシステムにマッピングされていたからです。1つのVMはgit-1.7.1を実行しており、もう1つのVMはgit-2.14を実行していました

git-1.7.1を実行しているVMは、常に4つのファイルが変更されたと表示します(内容と行末が同じであると考えていても)。

g-2.14を実行しているVMで「git status」が実行されると、両方のVMがリポジトリをクリーンとして報告し始めます。「git status」には副作用があります。不変の操作ではありません。そしてgit-1.7.1はgit-2 +のように世界を理解していません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.