bashを使用してWindowsXPマシンでgitを実行します。プロジェクトをSVNからエクスポートしてから、ベアリポジトリのクローンを作成しました。
次に、エクスポートをベアリポジトリディレクトリに貼り付け、次のことを行いました。
git add -A
次に、次のようなメッセージのリストを取得しました。
LFはCRLFに置き換えられます
この変換の影響は何ですか？これは、VisualStudioの.NETソリューションです。
825650 次
22 に答える
811
Git には、行末をどのように処理するかについて、次の 3 つのモードがあります。
$ git config core.autocrlf
# that command will print "true" or "false" or "input"
上記のコマンド ラインにtrueまたはのパラメータを追加することで、使用するモードを設定できます。false
が true に設定されている場合core.autocrlf、git がテキスト ファイルであると判断したファイルを git リポジトリに追加すると、コミットに保存する前にすべての CRLF 行末が LF になります。何かを行うたびにgit checkout、すべてのテキスト ファイルの LF 行末が CRLF 末尾に自動的に変換されます。これにより、行末スタイルが常に一貫して LF であるため、各エディターが行末スタイルを変更するため、コミットが非常に騒々しいことなく、異なる行末スタイルを使用するプラットフォーム間でプロジェクトの開発が可能になります。
この便利な変換の副作用 (これが表示されている警告の内容です) は、作成したテキスト ファイルが元々 CRLF ではなく LF で終わる場合、通常どおり LF で保存されますが、チェックすると後で CRLF エンディングが追加されます。通常のテキスト ファイルの場合、これで問題ありません。この場合、警告は「参考までに」ですが、git がバイナリ ファイルをテキスト ファイルであると誤って評価した場合、git がバイナリ ファイルを破損する可能性があるため、これは重要な警告です。
が false に設定されている場合core.autocrlf、行末の変換は実行されないため、テキスト ファイルはそのままチェックインされます。これは通常、すべての開発者が Linux またはすべて Windows を使用している限り、問題なく機能します。しかし、私の経験では、行末が混在するテキスト ファイルを取得する傾向があり、最終的に問題が発生します。
私の個人的な好みは、Windows 開発者として、設定をオンのままにすることです。
「input」値を含む更新情報については、https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-config.htmlを参照してください。
于 2009-12-28T04:37:30.200 に答える
282
既にコードをチェックアウトしている場合、ファイルは既にインデックス化されています。git の設定を変更したら、次のように実行します。
git config --global core.autocrlf input
インデックスを更新する必要があります
git rm --cached -r .
でgit indexを書き直します
git reset --hard
注: これにより、ローカルの変更が削除されます。これを行う前に、それらを隠しておくことを検討してください。
于 2015-04-27T06:33:57.457 に答える
90
git config core.autocrlf false
于 2014-03-21T04:34:58.113 に答える
52
unix2dosとdos2unixの両方が、Windows で gitbash を使用して利用できます。次のコマンドを使用して、UNIX(LF) -> DOS(CRLF) 変換を実行できます。したがって、警告は表示されません。
unix2dos filename
また
dos2unix -D filename
ただし、既存の CRLF ファイルに対してこのコマンドを実行しないでください。2 行ごとに空の改行が表示されます。
dos2unix -D filenameすべてのオペレーティング システムで動作するわけではありません。互換性については、このリンクを確認してください。
何らかの理由でコマンドを強制する必要がある場合は、 を使用します--force。無効と表示されている場合は、 を使用して-fください。
于 2011-05-01T23:50:54.803 に答える
32
このトピックについて話すとき、行末に関する GitHub の記事がよく言及されます。
頻繁に推奨されるcore.autocrlf構成設定を使用した私の個人的な経験は、非常に複雑でした。
私は Windows と Cygwin を使用しており、Windows と UNIX の両方のプロジェクトを異なる時期に扱っています。私の Windows プロジェクトでさえ、bashUNIX (LF) の行末を必要とするシェル スクリプトを使用することがあります。
Windows 用の GitHub の推奨core.autocrlf設定を使用して、UNIX プロジェクト (Cygwin で完全に動作します。または、Linux サーバーで使用するプロジェクトに貢献している可能性があります) をチェックアウトすると、テキスト ファイルは Windows でチェックアウトされます (CRLF ) 行末、問題の作成。
基本的に、私のような混合環境では、グローバルcore.autocrlfをどのオプションに設定してもうまくいかない場合があります。このオプションは、ローカル (リポジトリ) の git config で設定できますが、それでも、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 の貢献者も、このプロジェクトで作業するときに行末の問題を抱えることはありません。
于 2016-07-30T19:32:08.900 に答える
31
@Basiloungasの答えは近いですが、時代遅れだと思います（少なくともMacでは）。
~/.gitconfig ファイルを開き、safecrlffalse に設定します。
[core]
autocrlf = input
safecrlf = false
その*行末文字を明らかに無視します（とにかく、私にとってはうまくいきました）。
于 2014-07-19T08:10:05.930 に答える
21
vim でファイル (例: :e YOURFILEENTER) を開き、次に
:set noendofline binary
:wq
于 2012-02-21T10:08:21.957 に答える
18
私もこの問題を抱えていました。
SVN は行末の変換を行わないため、ファイルは CRLF 行末がそのままの状態でコミットされます。その後、git-svn を使用してプロジェクトを git に配置すると、CRLF 末尾が git リポジトリに残ります。これは、git が自分自身を見つけると予想される状態ではありません。デフォルトでは、unix/linux (LF) の行末のみが含まれます。チェックインした。
その後、Windows でファイルをチェックアウトすると、autocrlf 変換によってファイルはそのまま残ります (現在のプラットフォームで正しい末尾が既に設定されているため)。比較する前に、チェックアウトされたファイル内の LF であると考えられるものを、リポジトリ内の予期しない CRLF と比較します。
私が見る限り、あなたの選択肢は次のとおりです。
- git-svn を使用せずにコードを新しい git リポジトリに再インポートします。これは、最初のgit commit --allで行末が変換されることを意味します。
- autocrlf を false に設定し、行末が git の推奨スタイルではないという事実を無視します
- autocrlf をオフにしてファイルをチェックアウトし、すべての行末を修正し、すべてをチェックインして、再度オンにします。
- 元のコミットに git が想定していなかった CRLF が含まれないように、リポジトリの履歴を書き換えます。(履歴の書き換えに関する通常の警告が適用されます)
脚注:オプション #2 を選択した場合、私の経験では、一部の補助ツール (リベース、パッチなど) が CRLF ファイルに対応せず、遅かれ早かれ CRLF と LF が混在するファイルになってしまいます (一貫性のない行エンディング）。両方を最大限に活用する方法がないことを私は知っています。
于 2010-12-15T17:29:44.480 に答える
16
~/.gitattributes ファイルから以下を削除します
* text=auto
そもそもgitが行末をチェックするのを防ぎます。
于 2013-01-09T09:36:31.857 に答える
15
http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/ (動作していません)
.gitattributes ファイルのエントリを変更することで、CRLF の動作を完全に無効にすることも、ファイルタイプごとに無効にすることもできます。私の場合、私はこれを置きます：
- -crlf これは、すべてのファイルの行末を無視するように git に指示します。作業ディレクトリ内のファイルを変更しません。core.autocrlf を true、false、または入力に設定している場合でも。
echo "* -crlf" > .gitattributes
これを別のコミットで実行しないと、単一の変更を行ったときにファイル全体が変更されたものとして git に表示される場合があります (autocrlf オプションを変更したかどうかによって異なります)。
これは本当にうまくいきます。Git は、混合行末プロジェクトの行末を尊重し、それらについて警告しません。
于 2014-12-09T02:04:12.053 に答える
14
Windows のほとんどのツールは、テキスト ファイル内の単純な LF も受け入れます。たとえば、次のサンプル コンテンツ (一部) を使用して、「.editorconfig」という名前のファイルで Visual Studio の動作を制御できます。
indent_style = space
indent_size = 2
end_of_line = lf <<====
charset = utf-8
元の Windows のメモ帳だけが LF で動作しませんが、より適切でシンプルなエディター ツールが利用可能です!
したがって、Windows のテキスト ファイルでも LF を使用する必要があります。これは私のメッセージです、強くお勧めします！Windows で CRLF を使用する理由はありません。
(同じ議論は、C/++ のインクルード パスで \ を使用しています。それはでたらめです。スラッシュで #include <pathTo/myheader.h> を使用してください!、これは C/++ 標準であり、すべての Microsoft コンパイラがサポートしています)。
したがって、git の適切な設定は次のとおりです。
git config core.autocrlf false
私のメッセージ: dos2unix や unix2dos のような古い考え方のプログラムは忘れてください。LF が Windows での使用に適していることをチーム内で明確にします。
于 2020-05-17T09:43:24.343 に答える
10
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バイトです。
于 2009-12-27T23:39:58.763 に答える
6
OPの質問はWindows関連であり、管理者が機能しなかったため、ディレクトリに移動したり、メモ帳++でファイルを実行したりせずに他のユーザーを使用することはできませんでした..だから、このルートに行かなければなりませんでした:
C:\Program Files (x86)\Git\etc>git config --global core.autocrlf false
于 2015-03-31T14:39:40.667 に答える
3
GNU/Linux シェル プロンプトで、dos2unix & unix2dos コマンドを使用すると、MS Windows からのファイルを簡単に変換/フォーマットできます
于 2011-04-15T06:33:32.580 に答える