問題タブ [core.autocrlf]

Core.autocrlf設定のしくみに関するgitドキュメントだけでなく、スタック オーバーフローに関するさまざまな質問と回答も読みました。

これは私が読んだことからの私の理解です：

Unix および Mac OSX (OSX より前は CR を使用) クライアントは LF の行末を使用します。
Windows クライアントは CRLF 行末を使用します。

クライアントで core.autocrlf が true に設定されている場合、git リポジトリは常にファイルを LF 行末形式で保存し、クライアント上のファイルの行末は、チェックアウト/コミット時に前後に変換されます。 -LF 行末。クライアントの行末ファイルの形式に関係なく (これは、Tim Clem の定義と一致しません。以下の更新を参照してください)。

これは、core.autocrlf の 'input' および 'false' 設定について同じことを文書化しようとするマトリックスであり、行末の変換動作が不明な場合は疑問符が付いています。

私の質問は次のとおりです。

1. クエスチョンマークはどうあるべきですか？
2. このマトリックスは「非疑問符」に対して正しいですか?

コンセンサスが形成されているように見えるので、回答から疑問符を更新します。

さまざまな設定の長所と短所について意見を求めているわけではありません。私は、git が 3 つの設定のそれぞれで動作することを期待する方法を明確にするデータを探しています。

--

2012 年 4 月 17 日更新: コメントで JJD によってリンクされた Tim Clem の記事を読んだ後、上の表の「不明な」値の一部を変更し、「checkout existing | true to convert」を変更しました。クライアントに変換する代わりに CRLF に変換します。」これは彼が与えた定義であり、私が他の場所で見たものよりも明確です:

core.autocrlf = false

これはデフォルトですが、ほとんどの人はこれをすぐに変更することをお勧めします。false を使用した結果、Git がファイルの行末を台無しにすることはありません。LF、CRLF、CR、またはこれら 3 つのランダムな組み合わせでファイルをチェックインでき、Git は気にしません。これにより、差分が読みにくくなり、マージが難しくなる可能性があります。Unix/Linux の世界で働くほとんどの人は、CRLF の問題がなく、ファイルがオブジェクト データベースに書き込まれたり、作業ディレクトリに書き出されたりするたびに Git が余分な作業を行う必要がないため、この値を使用します。

core.autocrlf = true

これは、Git がすべてのテキスト ファイルを処理し、そのファイルをオブジェクト データベースに書き込むときに CRLF が LF に置き換えられ、作業ディレクトリに書き出すときにすべての LF が CRLF に戻されることを意味します。これは、作業ディレクトリに CRLF を保持しながら、他のプラットフォームでリポジトリを使用できるようにするため、Windows で推奨される設定です。

core.autocrlf = 入力

これは、Git がすべてのテキスト ファイルを処理し、そのファイルをオブジェクト データベースに書き込むときに CRLF が LF に置き換えられることを確認することを意味します。ただし、その逆は行いません。オブジェクト データベースからファイルを読み込んで作業ディレクトリに書き込むと、行末を示す LF がまだ残っています。この設定は通常、Unix/Linux/OS X で CRLF がリポジトリに書き込まれないようにするために使用されます。Web ブラウザーからコードを貼り付けて、誤って CRLF をファイルの 1 つに取り込んだ場合、Git は、オブジェクト データベースに書き込むときに、それらが LF に置き換えられることを確認します。

Tim の記事は素晴らしいものです。唯一欠けていると思うのは、リポジトリが LF 形式であると彼が想定していることです。これは、特に Windows のみのプロジェクトの場合、必ずしもそうではありません。

Tim の記事をjmlane によるこれまでの最高投票数の回答と比較すると、true 設定と入力設定が完全​​に一致し、false 設定が一致していないことがわかります。

現在のリリースと次のリリースの core.autocrlf および core.safecrlf 機能については、多くの議論がありました。ここでの質問は、開発者がベア リポジトリからクローンを作成する環境に関するものです。

複製中に autocrlf 設定が有効になります。ただし、開発者はクローンを完全に制御できるため、この autocrlf 設定を削除して続行できます。

1. .gitattributes ファイルでバイナリ以外のファイルを指定できますが、ファイルがテキスト ファイルかバイナリ ファイルかを GIT が自動的に判断する方法はありますか?

2. Windows 環境から裸のリポジトリをホストする UNIX マシンに (CRLF を使用して) ファイルをプッシュすることを確認するために配置できる、更新フック (開発者はまだそれを削除できるため、コミット フックは使用できません) のような方法はありますか? UNIX EOL 形式 (LF) に変換されますか?

3. 各ファイルの CRLF をスキャンする更新フックを使用すると、プッシュ操作のパフォーマンスに影響しますか?

ありがとう

この質問は私の他の質問と多少似てい ます。更新フックでファイルが CRLF から LF に変換されていることを確認してください。パフォーマンスに影響はありますか?

したがって、以下のアーキテクチャで探しているものは次のとおりです。1. 私の親リポジトリ (ベアおよびデータ) は UNIX マシン上にあります。2. UNIX マシンでリポジトリのクローンを作成できます。3. Samba を使用して Windows マシンでリポジトリを複製し、親リポジトリにアクセスできます。

次の場合、CRLF の問題に対処するにはどうすればよいですか

1. ユーザーは UNIX でクローンを作成し、samba を使用してそれを Windows ドライブにマップします。修正は Windows で行われ、CR/LF 文字ペアが EOL として作成されます。ユーザーが Unix に戻り、コミットしてプッシュする場合。GIT はどのように処理しますか? または、いくつかのフックを配置する必要がありますか?

2. 上記と同じですが、ファイル形式が 1 行あたり 8000 文字を超えています。これは、コミット時に CR が取り除かれた ASCII ファイルとして扱われますか?

3. バリエーション 2 ですが、ASCII ヘッダーを持つバイナリ ファイルです。これにより、うっかり CR/LF が LF に変更されることはありませんか?

ほとんどの場合、テキストファイル (em のほとんど) をステージングするたびに、git gui (msysgit を使用) から、行末が CRLF に置き換えられた (または置き換えられようとしている) というメッセージが表示されます。明らかに私はそれを望んでいます（そしてそれのための設定があります）が、迷惑なメッセージが常にポップアップするのは望ましくありません！

設定を維持し、ポップアップ メッセージをオフ/無効にする方法はありますか?

これがコマンドラインの GIT でどのように機能するかはわかりませんが、msysgit のステージング プロセスが好きです :) ので、bash に変更したくありません。

Git はコミット中またはviファイルの実行中に CRLF 変換を行いますか?

Windows に CRLF (Git リポジトリではない) を持ついくつかのファイルがあるとします。これらのファイルを UNIX Git リポジトリに同期し、autocrlf true有効にして git add/commit を実行すると、これらのファイルは CRLF から LF に変換されますか?

viまたは、これらのファイルを再度コミットした場合にのみ、これらのファイルの変換を行いますか?

2 番目の疑問は、親リポジトリが Unix に存在し、LF のみが必要な場合、Unix と Windows Git の両方のクローンでの設定はautocrlfどうあるべきかということです。safecrlfグローバル設定を使用する必要がありますか?

前もって感謝します

gitのCrLf設定に関連する複雑さを理解していません：core.autocrlf、core.safecrlf

私はチームでクロスプラットフォームプロジェクトを開発しており、WindowsとLinuxの両方の開発者が、行末のスタイルのためにファイルを変更済みとしてgitマークすることなく共同作業できるようにしたいと考えています。

さまざまな設定はどういう意味ですか？オプションのいずれかを選択した場合の結果はどうなりますか？そして、私の場合の最良の解決策は何でしょうか？

はい、私はこの質問を知っています、そしてそこでの答えは洞察に満ちていなかったので、役に立ちませんでした。

を介して設定できるオプションの当惑するほどの配列がありgit config、それは文書化されたものにすぎません。これらすべてのオプションのうち、すべての開発者が自分のボックスに設定する必要があるのはuser.emailどれですか? core.autocrlf=inputまた、一般的な状況 ( Windowsなど) で設定する必要がある最も一般的なものは何ですか? ただし、宗教的な議論には近づかないでください (存在の唯一の許容可能な設定などcore.whitespace) tab-in-indent。

Matlab .m ファイルは、Windows でも Unix LF の行末を使用します。他の通常のテキスト ファイルのように .m ファイルが CRLF に変換されないように、git 構成ファイルをセットアップしようと考えています (つまり、Windows であっても、レポ内のデフォルト スタイルとして LF を使用しています)。

これはできますか？

編集: Matlab 2008b マニュアルから。(M-ファイルの編集とデバッグの下)

Windows プラットフォーム用の MATLAB ソフトウェアで提供されるファイルで行末が削除されました。メモ帳アプリケーションでの表示への影響

以前のバージョンでは、Windows プラットフォーム用の MATLAB で提供されたテキスト ファイルには、各行の終わりにキャリッジ リターンとライン フィードが含まれていました。R2007b 以降、MATLAB が提供するテキスト ファイルには、各行の末尾にキャリッジ リターンとライン フィードが含まれていません。

影響を受けるファイル タイプは次のとおりです。

MATLAB やその他の一般的なテキスト エディターでファイルを表示しても影響はありませんが、Microsoft メモ帳アプリケーションの既知の例外があります。

互換性に関する考慮事項。Notepad アプリケーションを使用して MATLAB で提供されるファイルを表示すると、行末の代わりにキャリッジ リターンとライン フィード記号が表示されます。これにより、メモ帳アプリケーションでファイルが読みにくくなります。他のテキスト エディターでは、行末の代わりに記号が表示される場合がありますが、テストされた一般的なテキスト エディターの中で、そうするものは見つかりませんでした。

メモ帳アプリケーションの代わりに、Windows プラットフォームで提供される Microsoft ワードパッド アプリケーション、または別のテキスト エディタを使用してファイルを表示します。

私たちの上司と私だけが私たちのプロジェクトに取り組んでおり、私たちは開発専用にMacを使用しています。groovy / grailsの開発を行っており、Linuxサーバーにデプロイしています。開発プロセスのどこにもMSWindowsは使用されていませんが、bashシェルでgitを使用してファイルを比較している^Mと、CR（および改行と一緒にCRLF）を表す愚かな文字が表示されます。 ）。

これはどこからともなくファイルに現れています。

LFのみを行末として使用するようにIntelliJIDEAを設定する場所をオンラインで検索しましたが、見つかりませんでした。IDEAについての答えをグーグルで検索することの難しさは、ここでの私の欲求不満をさらに悪化させました。

私はこれらのことをしたい：

1. 私のマシン（OS X）でgitを構成して、CRLF を完全に拒否します。

2. また、中央リポジトリサーバー（Ubuntu Linux）のアクセスレイヤーとしてgitoliteを使用しています。ギトライトでCRLFの拒否を強制することが可能であれば、はるかに優れています。

3. 何もCRLFとして保存しないようにIntelliJIDEAを構成します。可能であれば、CRLFでいっぱいの既存のファイルの場合でも、スペースを追加して[保存]をクリックすると、すべてのCRLFが削除されます（単一のLFに変換されます）。

私は一般的にGitに非常に精通していると思いますが、CRLFを取り巻くすべての構成にひどく混乱しています。誰かが私の立場の誰かのためにこれらの設定のすべてがどうあるべきか教えてもらえますか？

ここでの主なポイントは、純粋に* nix/LF行終了の環境にあります。CRLFのナンセンスには対処したくありません。これは絶対に問題ではないはずです、そして私はそれを扱うのが嫌いです（あなたが言うことができなかった場合に備えて）。

CRLFを永遠に私の人生から外して欲しいです。

でレポを作成し、 でautocrlf=trueチェックアウトとコミットを行いましautocrlf=falseた。autocrlf=trueその後、 （OS Win）に戻りました。ブランチ間のマージを開始するまでは、すべて問題ないように見えました。多くのマージ競合が発生し、変更によりファイル全体が変更済みとしてマークされましたeols（チェックアウトされ、でコミットされたファイルだったと思いますautocrlf=false）。

私にとって価値のある歴史がいくつかあるので、eols新しいレポを作成して新しい生活を始めるよりも、何らかの変換を行うか、converted を使用してコミットを修正することを好みます。

これが私が理解している方法ですautocrlf（OS Win）：

ケースautocrlf=true

ケースautocrlf=false

で GIT を使用したいautocrlf=falseので、各ブランチをチェックアウトし、ユーティリティEOL コンバーターeolsでソース ファイルを修復し、CRLF でコミットすることにしました。私はそれを行いましたが、しばらくすると、設定をに変更した後にチェックアウトされなかったファイルがまだいくつかあります（または、これらのファイルは古い修正されていないコミットからマージされましたか？変換中にマスク *.filetype を使用して処理を自動化しました）すべての LF から CRLF への変換なので、このような状況について他に説明はありません)。また、ファイルをすべて再コミットしようとしましたが（ここでstackoverflowのどこかで見たように）、日付の変更はGIT AFAIKには関係ありません。autocrlfのダメージを元に戻す方法も読みましたautocrlffalsetouch、しかしそれが私の場合かどうかはわかりませんし、ウィザードのトリックも理解していません。

どうすればこの混乱から逃れることができますか?