13

同僚からのバンドルをマージした後、CRLF の問題を観察しました。LF を含む行がソースに混在している場合があり、おそらくマージされたものです。したがって、.gitattributes次の内容のファイルを追加することにしました (コメントは削除されています)。

*.cpp text
*.h text
*.inc text
*.cfg text
*.dic text

*.sln text eol=crlf
*.vcxproj text eol=crlf
*.filters text eol=crlf
*.user text eol=crlf
*.rc text eol=crlf
*.rc2 text eol=crlf

今、私は奇妙な行動を観察しています。modified: ...そこにあるはずのないファイル (つまり、ステージングされていないファイル) がたくさんあります。を試しgit reset --hardましたが、ファイルのステータスは同じです。リポジトリを再度クローンしようとしましたが、結果は同じでした。

Windows用の現在のバージョンとしてダウンロードしたものgit version 1.7.11.msysgit.0からインストールしました。Git-1.7.11-preview20120620.exe

他に何を試す必要がありますか？

ありがとう、ペトル

4

1 に答える 1

15

原因

この問題を引き起こすのは* text=auto設定です。.gitattributesそれを削除して、その後ずっと幸せに暮らすことができますが、レポのデフォルト以外の行エンコーディングのファイル、またはいくつかの異なる行末エンコーディング (つまり、LF と CRLF の両方、さらには CR!) のファイルがレポにある可能性があります。

なぜこうなるのか（詳細）

git がファイルをそのままチェックアウトすると、add/commit 時に行末が変更されます。ファイルは実際にはまだ変更されていませんが、レポの設定により になるため、git は既に変更済みと見なします。

どういうわけか、gitでは少し奇妙に動作します。たとえばgit reset --hard、おそらく設定によっては、機能する場合と機能しない場合があります。または、.gitattributes拡張子をバイナリとしてマークすると、変更されたファイルは魔法のように消えます。

*.ext binary

バイナリ マーキングを削除した後も、git reset --hard再度実行した後も効果が残るため、git バグまたは git キャッシュの問題である可能性があります。ファイルgit -rmに対して実行してから実行すると、変更されたマーキングgit reset --hardが復元されます。

修正方法

ここでは* text=auto、さまざまなテキスト ファイルの一貫性のない行末について git が現在および将来的に警告するように、設定を維持したいと想定しています。その場合は、方法を選択してください。

オプション 0 : ファイルが変更済みとしてマークされないように一時的に git を欺く

  1. 編集.gitattributes、コメントアウト* text=auto、保存
  2. git status(この手順は、.gitattributes で git レコードの変更を行うために必要です)
  3. git reset --hard(これにより、作業ディレクトリに変更を加えた場合は、その変更が復元さ* text=autoれ、削除されます)。

これは通常は機能します (おそらく最も頑固な場合を除きます)。また、行末がまだ正規化されていないため、後で発生する可能性が高い問題を延期します。

このオプションは、リベース中やその他の git 作業中など、正規化されていない以前のコミットを巻き戻す必要がある場合に最適です。既存の次のコミットが行末を正規化することはわかっていますが、git は変更されたファイルについて不平を言い、現在はあなたを妨げています。継続から。したがって、特定のコンテキストで実際には変更されていない変更済みファイルを git でシャットダウンして無視する必要がある場合は、基本的にこの方法を使用します。

オプション 1 : 簡単な「エンドユーザー」修正

ファイルが数個しかない場合は、.gitattributesandcore.autocrlfが好みに合わせて設定されていることを確認してから、 and を作成するだけで、git add/commitこの問題が再び発生することはありません。構成に記載されているように、ファイルは目的の行末に変換され、リポジトリに保存されます。このコミットは、「ファイル全体が変更された」としてリポジトリに保存されます。これは、すべての行で行末が変更されるためです。大規模またはオープンソースのリポジトリにあるいくつかのファイルの場合は問題ありません。問題は、修正するまで、それらのファイルがあったすべてのブランチに存在するため、すべてのブランチにそのコミットをマージまたはチェリーピックしてください。ところで、ここでオプション 0 を使用できます。つまり、修正されていないブランチに切り替えて問題が発生した場合は、オプション 0 を実行してから、修正 (マージまたはチェリーピック) を行います。

重要: オプション 1 のこのルートを使用する場合は、変更されたファイルを適切に変換してください。git はあなたの期待通りにそれをやっていないかもしれないので、コミットする前に自分でやってください。つまり、これを使ってください: Converting newlineformating from Mac to Windows LF、および CRLF 行末フォーマット。コミットする前に、それらを自分で好みの形式にNukeします。

オプション 2 : 高度なメカニズム「git 履歴の書き換え」の修正:

よりプライベートなリポジトリがあり、履歴を書き換えることを恐れない場合は、これを参照してください: git は、Mac の行末が原因でファイル全体を 1 行として認識します。 これにより、リポジトリ全体が書き換えられ、すべてのツリー、ブランチの行末の問題が解消されます。 、 永遠に！正規化する可能性のある問題を引き起こす可能性のあるすべてのテキスト ファイル拡張子を必ず含めてください。そうしないと、後で表示される可能性があります。

私の場合、多くのブランチで多くのファイル終了の問題を扱っていたため、オプション 2 を実行しました。しかしその後、正規化していない予期しない拡張子が表示され、オプション 1 を実行しただけでした。

于 2014-02-28T15:19:12.427 に答える