LFをCRLFに置き換えるgit

bashを使用して、Windows XPマシンでgitを実行します。SVNからプロジェクトをエクスポートし、ベアリポジトリのクローンを作成しました。

次に、エクスポートをベアリポジトリディレクトリに貼り付け、以下を実行しました。

git add -A

次に私は言っているメッセージのリストを得た：

LFはCRLFに置き換えられます

この変換の影響は何ですか？これはVisual Studioの.NETソリューションです。

これらのメッセージはcore.autocrlf、Windowsののデフォルト値が正しくないことが原因です。

の概念autocrlfは、行末変換を透過的に処理することです。そしてそうです！

悪いニュース：値は手動で設定する必要があります。
朗報：gitインストールごとに1回だけ実行する必要があります（プロジェクトごとの設定も可能です）。

どのようautocrlfな作品：

core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:

        repo                     repo                     repo
      ^      V                 ^      V                 ^      V
     /        \               /        \               /        \
crlf->lf    lf->crlf     crlf->lf       \             /          \      
   /            \           /            \           /            \

ここでcrlf= winスタイルの行末マーカー、lf= unixスタイル（およびMac OSX）。

（cr上記の3つのオプションのいずれについてもpre-osx は影響を受けません）

この警告が表示されるのはいつですか（Windowsの場合）

    - autocrlf= trueあなたは、UNIXスタイルを持っている場合はlf、ファイルのいずれかで（=めったに）、
    - autocrlf= inputあなたが勝つスタイルを持っている場合はcrlf、ファイルのいずれかで（=ほとんど常に）、
    - autocrlf= false- NEVER！

この警告はどういう意味ですか

「LFはCRLFに置き換えられます」という警告は、コミットチェックアウトサイクルの後で（autocrlf= を持っているtrue）UNIXスタイルのLFが失われることを示しています（WindowsスタイルのCRLFに置き換えられます）。Gitは、WindowsでUNIXスタイルのLFを使用することを期待していません。

警告「CRLFはLFに置き換えられます」は、コミットチェックアウトサイクルの後で（autocrlf= を持つinput）ウィンドウスタイルのCRLFが失われることを示します（UNIXスタイルのLFに置き換えられます）。input窓の下で使用しないでください。

さらにもう1つの方法は、どのように表示するautocrlf作品

1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x

ここで、xはCRLF（windowsスタイル）またはLF（unixスタイル）であり、矢印は

file to commit -> repository -> checked out file

直し方

のデフォルト値core.autocrlfはgitのインストール時に選択され、システム全体のgitconfig（%ProgramFiles(x86)%\git\etc\gitconfig）に保存されます。また、（次の順序でカスケード）もあります。

   - 「グローバル」（ユーザーごと）に位置gitconfig ~/.gitconfig、さらに別の
   -で「グローバル」（ユーザ単位）gitconfig $XDG_CONFIG_HOME/git/config又は$HOME/.config/git/configと
   の「ローカル」（毎レポ）gitconfig - .git/configワーキングディレクトリです。

したがって、git config core.autocrlf現在使用されている値を確認するために作業ディレクトリに書き込み、

   – autocrlf=falseシステム全体のgitconfigに追加＃システムごとのソリューション
   – git config --global core.autocrlf false            ＃ユーザーごとのソリューション
   –git config --local core.autocrlf false              ＃プロジェクトごとのソリューション

警告
– git config設定は設定によって上書きできgitattributesます。
– crlf -> lf新しいファイルを追加するときにのみ変換が行われます。crlf。リポジトリにすでに存在するファイルは影響を受けません。

道徳（Windowsの場合）：
    -使用core.autocrlf= trueあなたにもUnix上でこのプロジェクトを使用する（と不本意UNIXの改行コードを使用するようにエディタ/ IDEを設定する）を計画している場合、
    -使用core.autocrlf= falseあなたはWindowsでのみ、このプロジェクトを使用する場合（または、あなたのエディタ/ IDE UNIXの改行コードを使用する）を設定している、
    - 決して使用しないcore.autocrlf= inputあなたは（に正当な理由がない限り、例えば、あなたが窓の下またはあなたがメイクファイルの問題に実行する場合、UNIXユーティリティを使用している場合）、

PS Windows用のgitをインストールするときに何を選択しますか？
Unixでプロジェクトを使用しない場合は、デフォルトの最初のオプションに同意しないでください。3番目のものを選択します（現状のままチェックアウト、現状のままコミット）。このメッセージは表示されません。ずっと。

PPS私の個人的な好みは、Unixスタイルの末尾を使用するようにエディター/ IDEを構成し、に設定core.autocrlfすることfalseです。

Gitには、行末の処理方法に関する3つのモードがあります。

$ git config core.autocrlf
# that command will print "true" or "false" or "input"

trueまたはの追加パラメーターを使用して、使用するモードを設定できます。false上記のコマンドライン。

場合はcore.autocrlf、trueに設定されている手段はあなたがGitが考えているのgitリポジトリにファイルを追加した時間がテキストファイルであること、それがコミットでそれを保存する前に、それだけでLFに、すべてのCRLFの改行コードをオンにします。あなたがgit checkout何かをするときはいつでも、すべてのテキストファイルは自動的にそれらのLF行の終わりをCRLFの終わりに変換させます。これにより、行末スタイルは常に一貫してLFになるため、各エディターが行末スタイルを変更するため、コミット時に大きなノイズを発生させることなく、異なる行末スタイルを使用するプラットフォーム間でプロジェクトを開発できます。

この便利な変換の副次的影響であり、これが表示されている警告です。最初に作成したテキストファイルがCRLFではなくLFで終わる場合、通常どおりLFで保存されますが、チェックすると後でそれはCRLFエンディングを持っています。通常のテキストファイルの場合、これは通常は問題ありません。この場合、警告は「参考情報」ですが、gitがバイナリファイルをテキストファイルであると誤って評価した場合、gitがバイナリファイルを破損するため、これは重要な警告です。

もし core.autocrlf falseに設定されているテキストファイルが-があるように確認されているので、何の行末変換はこれまで、実行されません。これは通常、すべての開発者がLinuxまたはWindowsのいずれかである限り、問題なく動作します。しかし、私の経験では、結局問題が発生する行末が混在したテキストファイルを取得する傾向があります。

私の個人的な好みは、Windows開発者として、設定をオンのままにしておくことです。

「入力」値を含む更新情報については、http：//kernel.org/pub/software/scm/git/docs/git-config.htmlを参照してください。

すでにコードをチェックアウトしている場合、ファイルにはすでにインデックスが作成されています。git設定を変更した後、次のコマンドを実行します。

git config --global core.autocrlf input 

あなたはでインデックスを更新する必要があります

git rm --cached -r . 

そしてgitインデックスを次のように書き直してください

git reset --hard

https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings

注：これにより、ローカルの変更が削除されます。これを行う前に変更を隠しておくことを検討してください。

git config core.autocrlf false

unix2dosとdos2unixはどちらもgitbashを使用するWindowsで使用できます。次のコマンドを使用して、UNIX（LF）-> DOS（CRLF）変換を実行できます。したがって、警告は表示されません。

unix2dos filename

または

dos2unix -D filename

ただし、このコマンドを既存のCRLFファイルに対して実行しないでください。2行ごとに空の改行が取得されます。

dos2unix -D filenameすべてのオペレーティングシステムで動作するわけではありません。互換性については、このリンクを確認してください。

何らかの理由でコマンドを強制する必要がある場合は、を使用してください--force。無効と表示されている場合は、を使用してください-f。

@Basiloungasの答えは近いですが古くなっています（少なくともMacでは）。

〜/ .gitconfigファイルを開き、safecrlffalseに設定します

[core]
       autocrlf = input
       safecrlf = false

それは*文字の終わりを明らかに無視します（とにかく私のために働いた）。

A 行末にはGitHubの記事は、このトピックについて話すとき、一般的に言及されています。

頻繁に推奨される構成core.autocrlf設定の使用に関する私の個人的な経験は非常に複雑でした。

私はWindowsとCygwinを使用しており、WindowsプロジェクトとUNIXプロジェクトの両方を別々のタイミングで扱っています。私のWindowsプロジェクトでさえ、bashUNIX（LF）の行末を必要とするシェルスクリプトを使用することがあります。

GitHubのcore.autocrlfWindows の推奨設定を使用して、UNIXプロジェクト（Cygwinで完全に機能するか、またはLinuxサーバーで使用するプロジェクトに貢献している）をチェックアウトすると、テキストファイルはWindowsでチェックアウトされます（CRLF ）行末、問題の発生。

基本的に、私が持っているような混合環境では、グローバルcore.autocrlfをオプションのいずれかに設定しても、場合によってはうまく機能しません。このオプションはローカル（リポジトリ）のgit構成で設定される可能性がありますが、WindowsとUNIXの両方に関連するものを含むプロジェクト（たとえば、いくつかのbashユーティリティスクリプトを含むWindowsプロジェクトがある）には十分ではありません。

私が見つけた最良の選択は、リポジトリごとの.gitattributesファイルを作成することです。GitHubの記事はそれを言及しています。
その記事の例：

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

私のプロジェクトのリポジトリの1つで：

* text=auto

*.txt         text eol=lf
*.xml         text eol=lf
*.json        text eol=lf
*.properties  text eol=lf
*.conf        text eol=lf

*.awk  text eol=lf
*.sed  text eol=lf
*.sh   text eol=lf

*.png  binary
*.jpg  binary

*.p12  binary

設定するのはもう少しですが、プロジェクトごとに1回実行してください。どのOSのコントリビューターも、このプロジェクトで作業するときに行末で問題が発生しないはずです。

vimでファイル（例：）を開き:e YOURFILEENTER、次に

:set noendofline binary
:wq

私もこの問題を抱えていました。

SVNは行末変換を行わないため、ファイルはそのままCRLF行末でコミットされます。次にgit-svnを使用してプロジェクトをgitに入れると、CRLFの末尾はgitリポジトリ全体に残ります。これは、gitが自分自身を見つけることを期待している状態ではありません。デフォルトでは、unix / linux（LF）の行末しかありません。チェックインした。

その後、ウィンドウ上でファイルをチェックアウトすると、autocrlf変換はファイルに影響を与えません（ファイルには現在のプラットフォーム用の正しい終了があるため）。ただし、チェックインされたファイルとの違いがあるかどうかを判断するプロセスは、逆変換を実行します比較する前に、チェックアウトされたファイルのLFであると考えているものとリポジトリの予期しないCRLFを比較します。

私が見る限り、あなたの選択は：

1. git-svnを使用せずにコードを新しいgitリポジトリに再インポートします。これは、行末が最初のgit commit --allで変換されることを意味します
2. autocrlfをfalseに設定し、行末がgitの優先スタイルではないという事実を無視します
3. autocrlfをオフにしてファイルをチェックアウトし、すべての行末を修正し、すべてをチェックインして、再びオンに戻します。
4. リポジトリの履歴を書き直して、元のコミットにgitが予期していなかったCRLFが含まれないようにします。（履歴の書き換えに関する通常の警告が適用されます）

脚注：オプション＃2を選択した場合、私の経験では、補助ツールの一部（リベース、パッチなど）はCRLFファイルに対応せず、遅かれ早かれCRLFとLFが混在するファイル（一貫性のない行）になる末尾）。私は両方のベストを得る方法を知りません。

〜/ .gitattributesファイルから以下を削除する

* text=auto

gitが最初の場所で行末をチェックするのを防ぎます。

それは読むべきです：

警告：（それをチェックアウトするか、現在のcore.autocrlfである別のフォルダーに複製するとtrue、）LFはCRLFに置き換えられます

（現在の）作業ディレクトリで、ファイルの元の行が終了します。

この画像は、それが何を意味するかを説明する必要があります。

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/

echo "* -crlf" > .gitattributes 

個別のコミットでこれを行うか、gitが単一の変更を行ったときに、ファイル全体が変更されたと見なす可能性があります（autocrlfオプションを変更したかどうかによって異なります）。

これは本当に機能します。Gitは混合行末プロジェクトの行末を尊重し、それらについて警告しません。

Windowsでのgitについてはあまり知りませんが...

gitが実行中のプラットフォーム（Windows）の形式に一致するように戻り形式を変換しているように見えます。CRLFはWindowsのデフォルトの戻り形式ですが、LFは他のほとんどのOSのデフォルトの戻り形式です。

おそらく、コードが別のシステムに移動されたときに、戻り形式が適切に調整されます。また、gitは、たとえばJPEGでLFをCRLFに変換しようとするのではなく、バイナリファイルをそのまま維持するのに十分スマートだと考えています。

要約すると、おそらく、この変換についてあまり心配する必要はありません。ただし、プロジェクトをtarballとしてアーカイブする場合、他のコーダーはおそらくCRLFではなくLF行ターミネーターを使用することを望みます。気にかけている量（およびメモ帳を使用していない場合）に応じて、可能であればLFリターンを使用するようにgitを設定できます。

付録：CRはASCIIコード13、LFはASCIIコード10です。したがって、CRLFは2バイト、LFは1バイトです。

最新のgitがインストールされていることを確認してください。
上記のようにgit config core.autocrlf false、git（バージョン2.7.1）を使用しましたが、機能しませんでした。
その後、gitをアップグレードすると（2.7.1から2.20.1に）動作します。

1. Notepad ++でファイルを開きます。
2. 編集/ EOL変換に移動します。
3. Windows Formatをクリックします。
4. ファイルを保存します。

OPの質問はウィンドウに関連しており、管理者が機能しなかったため、ディレクトリに移動したりNotepad ++でファイルを実行したりせずに他のユーザーを使用することはできませんでした。

C:\Program Files (x86)\Git\etc>git config --global core.autocrlf false

多くのテキストエディターでは、に変更できますLF。以下のAtomの手順を参照してください。シンプルで明示的。

CRLF右下をクリックしてください：

LF上部のドロップダウンで選択：

GNU / Linuxシェルプロンプトでは、dos2unixおよびunix2dosコマンドを使用して、MS Windowsからのファイルを簡単に変換/フォーマットできます。

CRLFは、2つの異なるOS（LinuxとWindows）で「コード」を使用しているときに問題を引き起こす可能性があります。私のPythonスクリプトはLinux Dockerコンテナーで作成され、Windows git-bashを使用してプッシュされました。LFがCRLFに置き換えられるという警告が表示されました。私はあまり考えませんでしたが、後でスクリプトを開始したとき、それは言いました/usr/bin/env: 'python\r': No such file or directory。今、\rあなたのための分岐点のために。Windowsは「CR」を使用します-復帰-'\ n'の上に改行文字として- \n\r。それはあなたが考慮しなければならないかもしれないものです。

Windowsのほとんどのツールは、テキストファイルでLFのみを受け入れます。たとえば、次のサンプルコンテンツ（パーツ）を使用して、 '。editorconfig'という名前のファイルでVisual Studioの動作を制御できます。

 indent_style = space
 indent_size = 2
 end_of_line = lf    <<====
 charset = utf-8

オリジナルのWindows-NotepadのみがLFで動作しませんが、より適切なシンプルなエディターツールがいくつか利用可能です！

したがって、WindowsのテキストファイルでもLFを使用する必要があります。これは私のメッセージです。WindowsでCRLFを使用する理由はありません。

（同じ議論はC / ++のインクルードパスで\を使用しています、それはでたらめです、スラッシュで#include <pathTo / myheader.h>を使用してください！、これはC / ++標準であり、すべてのMicrosoftコンパイラがサポートしています）。

したがって、gitの適切な設定は

git config core.autocrlf false

私のメッセージ：dos2unixやunix2dosのような古い思考プログラムを忘れてください。LFがWindowsでの使用に適していることをチームで明確にします。