38

この質問と同じ問題が発生しています：git statusは変更を示していますが、gitcheckout-<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")
4

6 に答える 6

22

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

* -text

これにより、gitはどのファイルでもEOL変換を実行しないようになります。

于 2013-03-01T15:39:37.580 に答える
10

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

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

text ^^^^^^

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

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

于 2012-06-13T09:14:25.200 に答える
7

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

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

グローバル構成ファイルで、別のPCからコピーされたリポジトリの core.autocrlfgit status設定がない場合（複製されていない、コピーされているだけ）、コマンドを発行すると、すべてのテキストファイルが変更済み（gitattributesなし）としてマークされます。

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

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

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

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

于 2013-12-03T11:18:28.457 に答える
5

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

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


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

.gitattributes次の方法でファイルを検索します。

find <root-dir> -name .gitattributes

そしてgrep、またはあなたの犯人を見つけて、必要に応じて修正するためにtext。eolcrlf

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

于 2013-03-28T17:05:48.560 に答える
1

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

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

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

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

于 2014-01-13T08:36:52.657 に答える
0

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

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

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

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

于 2013-02-14T22:45:56.463 に答える