web-dev-qa-db-ja.com

git statusは、autocrlf = falseでも変更を示します

私はこの質問と同じ問題を経験しています： git statusは変更を示し、git checkout-<file>はそれらを削除しません

Gitは、git config --global core.autocrlf falseを使用しても、引き続き作業ディレクトリの変更を表示します。

E:\_dev\github\Core [master +0 ~93 -0]> git config --get-all core.autocrlf
false
false

（--system設定をfalseに設定したことに注意してください）

Gitがまだ行末を変更しているように見えるのはなぜですか？

変更を取り除く試み

ベースライン

E:\_dev\github\Core [master +0 ~93 -0]> git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   tools/StatLight/StatLight.EULA.txt
... more changes ...
no changes added to commit (use "git add" and/or "git commit -a")

gitcheckout-。

E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed) 
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   tools/StatLight/StatLight.EULA.txt
... more changes ...
no changes added to commit (use "git add" and/or "git commit -a")

時折、これは奇妙な方法で影響を及ぼします：

E:\_dev\github\Core [master +0 ~628 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~361 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .

git reset --hard

E:\_dev\github\Core [master +0 ~93 -0]> git reset --hard
HEAD is now at 11a7f9a Merge pull request #8 from RemiBou/master
E:\_dev\github\Core [master +0 ~93 -0]>

gitadd。; git stash; git stash drop

E:\_dev\github\Core [master +0 ~93 -0]> git add .
... warnings ....
warning: CRLF will be replaced by LF in tools/StatLight/StatLight.EULA.txt.
The file will have its original line endings in your working directory.

E:\_dev\github\Core [master +0 ~93 -0]> git stash
Saved working directory and index state WIP on master: 11a7f9a Merge pull request #8 from 
RemiBou/master
HEAD is now at 11a7f9a Merge pull request #8 from RemiBou/master

E:\_dev\github\Core [master +0 ~93 -0]> git stash drop
Dropped refs/stash@{0} (de4c3c863dbad789aeaf563b4826b3aa41bf11b7)

E:\_dev\github\Core [master +0 ~93 -0]> git status .\tools\StatLight\StatLight.EULA.txt
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   tools/StatLight/StatLight.EULA.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
gitrevertgit-statuscore.autocrlf
36
codekaizen

これは確かにmsysgitのバグのようです。回避策として、 。gitattributes を含むファイルを作成してみてください

* -text

これにより、ファイルに対してEOL変換を実行しないようにgitに指示されます。

20
Brecht Machiels

.gitattributesファイルがないか確認してください

gitattributes manページの "Effect"セクション で述べたように、これらのファイルはeolおよび自動変換にも影響を与える可能性があります。

text ^^^^^^

この属性は、行末の正規化を有効にして制御します。
テキストファイルが正規化されると、その行末はリポジトリ内でLFに変換されます。
作業ディレクトリで使用される行末スタイルを制御するには、単一のファイルにeol属性を使用し、すべてのテキストファイルにcore.eol構成変数を使用します。

「 異なるオペレーティングシステム間でのcore.eolでの行末変換の動作方法 」で説明されているように、git core.autocrlfの構成も確認してください。

10
VonC

MSysGitでのcore.autocrlfの奇妙な動作を調査していますが、次のことがわかりました。

[core]
    autocrlf = false
    safecrlf = true
    ignorecase = true
    eol = native

グローバル設定ファイルで、別のPCからコピーされたリポジトリでNOcore.autocrlf設定（複製されていない、コピーされているだけ）、git statusコマンドを実行すると、すべてのテキストファイルが変更済みとしてマークされます（周囲にgitattributesはありません）。

ただし、ローカル（リポジトリ）core.autocrlf設定をtrueに追加してから、git statusコマンドを発行すると、all変更が消え、リポジトリはクリーンに戻ります。

しかし（これは奇妙な動作です）、追加したcore.autocrlf設定をリポジトリー構成ファイルから削除すると（したがって、正確な初期状態に戻ります）、git statusコマンドは変更を報告し続けます ！！

リポジトリで操作が実行されていないことを考えると、構成設定を変更し、元の状態に戻すだけで、トリックが実行されます...

これがバグでなければ、世界の誰がこれを「通常の」動作と呼ぶことができるか想像できません。

7
nexbit

この問題は、 gitattributesのテキストオプションによって発生する可能性があります。

ドキュメントを注意深くお読みください。ただし、基本的にautocrlfは、textが.gitattributesに設定されていない場合にのみ重要です。

詳細不明
text属性が指定されていない場合、gitはcore.autocrlf構成変数を使用して、ファイルを変換する必要があるかどうかを判断します。

.gitattributesファイルを見つけるには：

find <root-dir> -name .gitattributes

そして、grep for text、eolまたはcrlfを使用して原因を見つけ、必要に応じて修正します。

このファイルを変更して、問題を解決するのに十分な時間コミットせずに変更を元に戻すことができます。

5
Cris Favero

「autocrlf」問題は、 クロス マルチプラットフォームリポジトリ（つまり、Linuxのサーバー上でtortoisegitとのsamba共有を使用する）

私は時々（しばしば）、それはautocrlfの問題よりも「chmod」の問題であることに気づきました：-git statuswindowsは変更待ちを表示します--gitstatuslinuxは何も表示しません

「モード変更100755 => 100644 config /packager.xml」

「静的」ファイルが+ xでないことを確認してください（この場合、tortoisegitはそれを気に入らないでしょう）

1
131

この奇妙な動作の原因はわかりませんが、機能する可能性のある変更を破棄するもう1つの方法を知っています。

警告！非常に注意して、最初にバックアップを実行してください。これは非常に破壊的です。

気になるすべてのデータがリポジトリにコミットされている場合、作業ディレクトリ（もちろん非表示の.gitディレクトリを除く）内のすべてを削除するだけで済みます。 git reset --hard HEADを実行して、リポジトリデータからのみ作業ディレクトリをgitに再作成させます。

これを行う前に、gitによって追跡されていない重要なデータがないかどうかを注意深く確認することを忘れないでください。コミットされていない変更がないかgit statusをチェックするだけでは不十分です-作業ディレクトリからすべてのファイルを削除すると、gitに無視するように指示したファイルも削除され、git reset --hard HEADで再作成されないことに注意してください。まったく追跡されません。

0
Jan Warchoł