3

私は Windows 7 で Github for Windows を使用していますが、ファイルがまったく変更されていない場合でも、ファイルのピンク色の壁が表示されることがあります (次の図に示すように)。これについて話している記事を見つけましたが、良い解決策が見つかりません。ファイル内のCRLF文字をLFに変更するのではなく、Github for Windows を正しく動作させる方法はありますか? 私はCRLFが好きです....

ピンクの壁

4

2 に答える 2

2

私はCRLFが好きです....

誰もが Windows で行います ;-)

ただし、Git はテキスト コンテンツを LF 行末区切り記号で内部的に保存することを好みます。

ただし、作業ディレクトリの CRLF と git オブジェクト データベースの LF の両方を持つことができます。それを容易にする git 組み込みメカニズムがあります。

実際、Scott Hanselman の投稿で述べられているように、

[...] GitHub for Windows が text=auto で提案していることを実行できます (そして、次の行を含むリポジトリごとに.gitattributesファイルを作成します)。

# Auto detect text files and perform LF normalization 
* text=auto

text=autoは何をしますか?

これにより、git がテキストと見なすすべてのファイルが、リポジトリ内で正規化された (LF) 行末を持つようになります。core.eol 構成変数は、git が作業ディレクトリ内の正規化されたファイルに使用する行末を制御します。デフォルトでは、プラットフォームのネイティブの行末を使用するか、core.autocrlf が設定されている場合は CRLF を使用します。

もう 1 つの非常に役立つコンテンツは、Tim Clem の投稿Mind the End of Your Lineです。これは、Git 行末の理由と方法を見事に説明しています。

アップデート

nulltoken、プロジェクト フォルダーに .gitattributes があり、text=auto がありますが、github クライアントはピンク色の壁を何度も表示します。

上記のコメントに続いて、考慮すべきいくつかの追加点を以下に示します。これにより、いくつかの git コマンドを実行するためにコマンド ラインに切り替える必要があります。

  • .gitattributesファイルがコミットされており、プロジェクト フォルダーにあるだけではないことを確認してください。
  • 何も失わないようにするために、保留中の変更がないことを確認してください（たとえば、実行git statusすると次のような出力が必要ですnothing to commit, working directory clean）
  • 実行しますgit checkout-index --force *。これにより、ファイル内のディレクティブを考慮して、作業ディレクトリ内のすべてのファイルが再作成され.gitattributesます。これが完了すると、作業ディレクトリ内のすべてのテキスト ファイルに CRLF 行末が付きgit status、workdir はクリーンであると見なされます。
  • 今後、新しいコミットを作成するときに Wall of Pink が表示されることはありません。

注:ファイルを含むコミットの前に作成された、履歴内の 2 つのコミット間の変更を表示している間、ピンクの壁が引き続き表示される場合があり.gitattributesます。

于 2013-10-16T05:46:32.637 に答える
0
  1. Notepad++ でファイルを開きます。
  2. 編集/EOL 変換に移動します。
  3. UNIX/OSX 形式をクリックします。
  4. ファイルを保存します。
于 2013-10-16T08:16:58.270 に答える