マインドザライン

導入
ファイルが別のOS上で作成されたため、行の終わりの問題がありますか?私は実際に行の終わりを使用していた奇妙なハードトラブルを解決する私の依存関係のいずれかのバグtxt ファイル.いいえ、大変です.私は、バナナに行くことから私の正気を保つために、16進エディタを使いました.それはあなたが長いと疲れ切っているコーディングセッションの後にすることを終えることができたものであるので、進んで、このポスト(JK)の残りを読むことによって、あなた自身に好意を持ってください🤣
この記事では、私は簡単にこの問題について議論しますCR AND LF ASEOL 文字は、UnixはLF . 他のどんなキャラクタとしても、行終わりは順番にバイトでコード化される数でコード化されます.The ASCII 文字符号化規格はそれらの文字を数字に写像する責任があります.技術的にはCRLF より正確ですが、後でこれ以上.
行終了文字EOL , CR and LF) are control characters , 彼らが見えないという意味.彼らの役割は、コンピュータに特定の行動について知らせるために、そして、ユーザーに視覚的価値のないです.彼らが異なる線結末を持つことができた2つの一見同一のファイルを観察している間、彼らが見えないという事実は怒りと欲求不満を引き起こすことがありえます.違いを伝えることができる唯一の方法は、16進数のエディタを使ってバイトでバイトを比較することです.最後に、gitがデフォルト値として“native”を使う点に注意することが重要ですcore.eol どのような行の終了を使用することを意味する設定は、OSによって指定されます.
LF : ラインフィードLF “ラインフィード”を表します.よく知られている改行シーケンスは\n . このコントロール文字は新しい線を示し、カーソルを1行下に動かすよう指示します.
CR : 復帰CR 「復帰」を表します.エスケープシーケンスは\r そして、現在の行の先頭に戻るようにコンピュータに通知します.
CRLF : キャリッジリターン-ラインフィード
これらの2つの文字を結合すると、ワープロの“Enter”キーを押すと、それらの2つの文字がどのようなものになるかがわかる.

カーソルを行の先頭に戻します.

つの行を下に移動します.

それは実際にどのように初期のタイプライターが働いた.

バグ
行の終わりの問題は、デフォルトでgitがCRLF を使用する場合LF Unix/OS Xを使っているなら、何があっても.場合は、特定の方法で行の終了を扱うためにgitを設定していない場合は.gitattributes 特定のファイルを強制するEOL 文字はあなたの頭痛の原因となる.それは、異なるOSでコミットされた依存関係が読んでいたときに私が遭遇したものですtxt ファイルシステムからのファイルと\n ( LF ). 私はWindowsマシンを使用していたので、gitは静かにそれらを変換していたCRLF ( \r\n ). したがって、アプリケーションは奇妙なバグを生成します.
さらにイライラしていたのはgit-diff オリジナルファイルとローカルコピーとの間には何の違いもありません.ファイルは一見同じでした!過去に、私は線の終わりで、しかし、この程度ではなく混乱していました.コーディングの長い時間のために脳の霧を持って、私はちょうど16進エディタを開き、バイトを検査することを決めた.ブーム!私はすぐに違いに気づき始めた.それで、私は少なくともファイルが本当に異なっていたと確信しました.より近い外観をとることによって、1つはバイトが各々の語の後で異なることを見ることができました.そして、それがすべてが意味をなし始めた点です.

フィックス
オリジナルファイルの検査後EOL どれがLF , 私はすぐに.gitattributes ファイル強制LF ラインエンドtxt ファイル

* text=auto eol=lf

この規則はGitのfiletype検出アルゴリズムを解決するために利用されているtxt ファイルと施行LF 両方のチェックアウトとコミットの行の終了.
を追加する前に.gitattributes ファイルをくりこみます.これは以下のコマンドを実行します.

git add --renormalize .

このコマンドは、Git index , 効果的にコミットのファイルをステージングします.現在の作業ツリーは更新されません-あなたは再-fetch . すべてのファイルが使用されるようにするLF 次のコマンドを実行します.

git ls-files --eol

# This will print:
# i/lf    w/crlf  attr/text=auto eol=lf   file.txt
#
# Where:
# i = Index line-endings
# w = Working tree line-endings
# attr = Any .gitattributes rules that may apply

迅速な歴史
問題を調査している間、私は本当に徹底的に話題を理解するために、私が本当にあなたを読むのを奨励する若干の本当に面白い歴史的な文脈を見つけました.
としてIntroduction part of this post, EOL characters were inspired by early typewriters. Back in the day, when typing on such a machine, the typist needed to feed a paper sheet to the machine. On each keystroke the machine would print the letter onto the sheet and move the carriage so that the next letter would appear to the right of the previous one. Additionally, the carriage needed to be reset when inserting a new line. So, the process of writing into a new line involved resetting the carriage, as well as rotating it to move the sheet upwards. Resetting the carriage amounts to CR and rotating the carriage to LF . Who would've though, eh?

Now, regarding Windows vs UNIX ( CRLF vs LF ), it's obvious that, while redundant nowadays, CRLF represents the whole process of "inserting a new line", abiding to the original convention. To me, as long as everything is configured correctly, I don't really care at all 😅 

参考文献

https://www.aleksandrhovhannisyan.com/blog/crlf-vs-lf-normalizing-line-endings-in-git/

https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings#global-settings-for-line-endings

https://en.wikipedia.org/wiki/Control_character