warning: in the working copy of 'hello.txt', LF will be replaced by CRLF the next time Git touches it は、「手元のフォルダ（作業ツリー）にあるこのファイルの改行は LF ですが、次に Git がこのファイルを手元のフォルダに書き出したとき、CRLF に変わります」という知らせです。改行コードは行の終わりに入る見えない文字で、LF は \n の 1 文字、CRLF は \r\n の 2 文字です。
warning:（警告）なので git add は止まらず、その時点では手元のファイルも変わりません（Git の文書、gitattributes）。Linux の Git で試した結果、コミットに入った中身は LF のままで、書き出し直したあとも git status --short に変更は出ませんでした。ただし Git の文書（git-config）は、改行の変換はまれにデータを壊し、テキストと見なされたバイナリでは壊れうる、と書いています。
この警告は、たとえば core.autocrlf を true（作業ツリーは CRLF、リポジトリの中は LF にしたいときの設定）にして、改行が LF のファイルを git add すると出ます（Git の源（ソースコード）のコミットの説明にある手順です）。Git for Windows のインストーラーの源（2026年10月23日に見た版）で、既定に選ばれているのがこの true です。
改行の扱いをリポジトリで決めるなら、Git の文書は、リポジトリに .gitattributes を置いて全部のファイルに text=auto を付ける（* text=auto）と、誰が入れたファイルでも、リポジトリの中の改行が LF にそろう、と書いています。GitHub の文書も、.gitattributes をリポジトリの根に置いてコミットするよう案内しています。ただし core.autocrlf=true のままだと、* text=auto だけでは警告が出ました。* text=auto eol=lf にすると、LF のファイルには出ませんでした（試した結果。止め方として勧める文書はありません）。詳しくは「.gitattributes と core.autocrlf はどちらが効く？」の節に書きました。まずは、いまの core.autocrlf の値とそれを書いた設定ファイル、ファイルごとの改行を見ます。
git config --show-origin core.autocrlf
git ls-files --eol--show-origin は、値と、それを書いた設定ファイルを出します。--eol の i/ はインデックス（次のコミットの候補）、w/ は作業ツリーの改行です。w/crlf なら手元のファイルが CRLF です。attr/ は、書き出しやコミットのときに使われる改行の属性です（Git の文書）。空のファイルには、改行の属性（text・eol）が当たっていません。
確かめたのは Linux の Git（2.56.0 など 4 つの版）で、Windows では実行していません。Git for Windows のインストーラーの源で既定に選ばれている core.autocrlf=true を入れて試しました。
- 警告は「次に Git がファイルを書き出したとき、LF が CRLF に変わる」という知らせ。
git addは止まらない。試した結果、リポジトリに入った中身は LF のままだった core.autocrlf=trueで LF のファイルを入れると「LF→CRLF」、inputで CRLF のファイルを入れると「CRLF→LF」が出た（試した結果）。値と出どころはgit config --show-origin core.autocrlfで見る- 改行をリポジトリで決めるなら
.gitattributes（* text=auto、種類ごとにeol=lf・eol=crlf・binary） core.autocrlf=trueのままだと、* text=autoだけでは警告が出た（試した結果）- もう入っているファイルは
git add --renormalize .でそろえ直す
\\ 3丁目オーナー開発アプリ！コンテンツ随時更新中 //
\\ これからITフリーランス //
\\ 3丁目オーナー開発アプリ！コンテンツ随時更新中 //
\\ これからITフリーランス //
「LF will be replaced by CRLF the next time Git touches it」とは？
この警告は、次に Git がこのファイルを書き出したとき改行が変わる、という知らせです。警告の文は、Git の源（convert.c）では 2 通りです。どちらも warning: で始まります。
in the working copy of '<ファイル>', LF will be replaced by CRLF the next time Git touches it（LF のファイルが CRLF に変わる）in the working copy of '<ファイル>', CRLF will be replaced by LF the next time Git touches it（CRLF のファイルが LF に変わる）
警告が出るのは、変換が往復で元に戻らないと見つけたときです。Git の源では、core.safecrlf を設定しないとき、警告だけを出して続ける（warn）のが既定です。
文を今の形に変えたのは、Git の源のコミット（2022-04-07）です。コミットの説明は、前の文について、2 つの文がどちらも「will」を使っていて同じ時を指すように読めること、「original line endings」の「original」が LF か CRLF か分からないことを挙げ、いつ・何に変わるかをはっきりさせる、と書いています。
Git 本体の源の訳の一覧（2.56.0）には日本語（ja）がありません。手元で LANG=ja_JP.UTF-8・LANGUAGE=ja にして試した結果も英語のままでしたが、手元の 2.56.0 は訳を出す部品を外して作り、ほかの版を流した環境にも日本語の表示の設定（ロケール）が入っていなかったので、手元の結果だけでは言えません。Git for Windows などの道具が日本語で何と出すかは、確かめていません。
確かめた版は、Linux の Git 2.56.0（2026年10月時点の最新。源から作ったもの）・2.43.0（Ubuntu 24.04.5 LTS）・2.54.0 と 2.36.3（Docker の alpine/git）です（2026年10月23日に実行しました）。出力は 2.56.0 のもので、2.36.3 は警告の文が違いました。コミットのハッシュは、流すたびに変わる例です。
「the next time Git touches it」はいつ？
Git の文書（gitattributes）は、git add そのものは作業ツリーのファイルを触らず、次の checkout が触る、と書いています（原文は "the next checkout would"）。どの操作が「触る」に当たるかを並べた文書は、見つかっていません。git add の使い方は、【Github初心者】Gitコマンドのよく使う使い方を基本から学ぶの「git add」の節にあります。
手元で試した結果は次のとおりです。core.autocrlf=true で LF のファイルを git add して、コミットしたあとも、ファイルの中身は \n のまま、git ls-files --eol は i/lf w/lf でした。そのファイルを rm で消して git checkout -- hello.txt で書き出し直すと、\r \n になり、i/lf w/crlf に変わりました。そのあとの git status --short は空でした。
od -c は、ファイルの中身を 1 バイトずつ、見える文字か \n・\r のような記号で出すコマンドです。行の終わりが \n だけなら LF、\r \n なら CRLF です。
$ git config --show-origin core.autocrlf
file:.git/config true
$ git add hello.txt
warning: in the working copy of 'hello.txt', LF will be replaced by CRLF the next time Git touches it
$ git status --short
A hello.txt
$ git commit -q -m first
$ git ls-files --eol
i/lf w/lf attr/ hello.txt
$ od -c hello.txt
0000000 H e l l o w o r l d ! \n
0000015
$ rm hello.txt
$ git checkout -- hello.txt
$ od -c hello.txt
0000000 H e l l o w o r l d ! \r \n
0000016
$ git ls-files --eol
i/lf w/crlf attr/ hello.txt
$ git status --short逆向きの「CRLF will be replaced by LF」
core.autocrlf=input で、CRLF のファイルを git add した結果です。input は、書き出すときの変換をしない設定です（Git の文書）。インデックスには LF で入り、書き出し直すと、手元のファイルも LF になりました。
$ od -c hello.txt
0000000 H e l l o w o r l d ! \r \n
0000016
$ git add hello.txt
warning: in the working copy of 'hello.txt', CRLF will be replaced by LF the next time Git touches it
$ git commit -q -m first
$ git ls-files --eol
i/lf w/crlf attr/ hello.txt
$ rm hello.txt
$ git checkout -- hello.txt
$ od -c hello.txt
0000000 H e l l o w o r l d ! \n
0000015
$ git ls-files --eol
i/lf w/lf attr/ hello.txtGit 2.36 までの「The file will have its original line endings in your working directory」
古い警告の文で調べてここに来た人向けです。Git 2.36 までの警告は、2 行で出ました。Git 2.37.0 から、今の 1 行の文に変わっています（変えたコミットが入った最初の正式版が 2.37.0 です）。Git 2.36.3 で、上の core.autocrlf=true の git add hello.txt を流すと、次のように出ました。2 行目の終わりに . は付きません。
$ git add hello.txt
warning: LF will be replaced by CRLF in hello.txt.
The file will have its original line endings in your working directoryCRLF の側も同じ形で、warning: CRLF will be replaced by LF in hello.txt. のあとに同じ 2 行目が付きました。手元の 4 つの版で試した結果、警告が出る・出ないは同じで、警告の文で違ったのは形だけでした。変えた理由は、前の節に書いたコミットの説明のとおりです。
どんなときに出る？ core.autocrlf の true・input・false
手元の結果は、Linux の Git 2.56.0 で、リポジトリの設定（git config core.autocrlf <値>）に入れて試したものです。
| 値 | 意味 | 手元で警告が出たか（試した結果） |
|---|---|---|
true | Git の文書（git-config）: 作業ツリーは CRLF、リポジトリは LF にしたいときの設定（全部に text=auto・core.eol=crlf と同じ）。インストーラーの説明: 「Checkout Windows-style, commit Unix-style line endings」。ほかの OS と一緒に使うプロジェクトでは、Windows で勧める。既定に選ばれている値 | LF のファイルを add すると「LF will be replaced by CRLF」 |
input | Git の文書: 書き出すときの変換をしない。インストーラーの説明: 「Checkout as-is, commit Unix-style line endings」。ほかの OS と一緒に使うプロジェクトでは、Unix で勧める | CRLF のファイルを add すると「CRLF will be replaced by LF」 |
false | Git の文書の段落に説明は無い。インストーラーの説明: 「Checkout as-is, commit as-is」。変換をしない。ほかの OS と一緒に使うプロジェクトでは勧めない | 属性なしで LF のファイルを add すると、何も出なかった |
意味の列の「インストーラーの説明」は、Git for Windows のインストーラーの源（2026年10月23日に見た版）の説明です。
Git 本体の源では、core.autocrlf の既定は false です（文書には書かれていません）。false の行の「何も出なかった」は、比べるために流しただけで、直し方として勧める文書はありません。
GitHub の文書は macOS・Linux に input、Windows に true を勧めています。Git 本体の既定は false（源）で、git の文書は勧める値を書いていません。この記事は、どの値も勧めません。
自分の設定を確かめる（git config --show-origin）
git config --show-origin core.autocrlf は、値と、それを書いた設定ファイルを出します。手元で上の core.autocrlf=true を入れたリポジトリでは、file:.git/config のあとにタブ（字下げの文字）をはさんで true と出ました。Windows で何と出るかは、確かめていません。
Git for Windows のインストーラーの既定
Git for Windows のインストーラーの源（2026年10月23日に見た版）には、改行の画面があり、選択肢は 3 つです。それぞれ core.autocrlf を true・input・false にします（上の表の「インストーラーの説明」）。
この源で既定に選ばれているのは 1 つ目（true）です。前に入れたときの選択があれば、それを使います。選んだ値は、system の設定（git config --system）に書かれます。どのリリースのインストーラーがこの源から作られたかは、確かめていません。Windows で入れて確かめてもいません。
どのファイルが CRLF か確かめる（git ls-files --eol）
git ls-files --eol は、インデックス（i/）と作業ツリー（w/）の改行と、効いている属性（attr/。.gitattributes でファイルに付けた印）を、ファイルごとに出します。Git の文書（git-ls-files）では、改行の値は -text・none・lf・crlf・mixed・空のどれかで、空は「通常のファイルでない・インデックスに無い・作業ツリーで読めない」ときです。表示の形は i/<値> w/<値> attr/<属性> のあとにタブ、ファイル名です。
読み方を先に書きます。w/crlf なら手元のファイルが CRLF です。attr/ は、書き出しやコミットのときに使われる改行の属性です（Git の文書）。空のファイルには、改行の属性（text・eol）が当たっていません。
手元（Linux の Git 2.56.0）で、core.autocrlf を設定していないリポジトリに次の 6 つのファイルを用意し、.gitattributes に *.txt text=auto と mixed.txt -text を書いて、git add . したあとに流した結果です。Git の文書によると、eol も core.autocrlf・core.eol も無いときの書き出しの改行は、Windows では CRLF、ほかでは LF なので、Windows では警告の出方が違うことがあります（確かめていません）。
| ファイル | 中身 |
|---|---|
lf.txt | a と LF |
crlf.txt | a と CRLF |
mixed.txt | CRLF の行と LF の行が混ざっている |
none.txt | 改行が無い a だけ |
bin.dat | NUL（0 の文字）を含む |
.gitattributes | 上の 2 行 |
$ cat -n .gitattributes
1 *.txt text=auto
2 mixed.txt -text
$ git add .
warning: in the working copy of 'crlf.txt', CRLF will be replaced by LF the next time Git touches it
$ git ls-files --eol
i/lf w/lf attr/ .gitattributes
i/-text w/-text attr/ bin.dat
i/lf w/crlf attr/text=auto crlf.txt
i/lf w/lf attr/text=auto lf.txt
i/mixed w/mixed attr/-text mixed.txt
i/none w/none attr/text=auto none.txtcrlf.txt は、text=auto が当たり、作業ツリーは CRLF のまま、インデックスには LF で入ったので、i/lf w/crlf です。
ファイル名を渡すと、そのファイルだけが出ます。lf.txt を CRLF の中身に書き換えたあとに流すと、インデックスは入れたときのまま、手元だけが変わって見えます。
$ git ls-files --eol lf.txt
i/lf w/crlf attr/text=auto lf.txt.gitattributes で改行コードを決めるには？
.gitattributes とは（置き場はリポジトリの根）
.gitattributes は、ファイルのパターンごとに属性（改行の扱いなど）を決める設定ファイルです。GitHub の文書は、リポジトリの根に置いて、ほかのファイルと同じようにコミットするよう案内しています。
パターンの書き方（*・**・/）は、.gitignore の書き方と同じです。ただし、Git の文書によると、!（取り消し）は使えません。フォルダに当たるパターンは中のファイルに及ばないので、path/ ではなく path/** と書きます。複数の行が当たったときは、あとの行が勝ちます（属性ごと）。だから * text=auto を先頭に書き、種類ごとの行をあとに書きます。
text・text=auto・eol=lf・eol=crlf・binary の違い
| 書き方 | Git の文書 | GitHub の文書 |
|---|---|---|
text | テキストの印。入れるとき LF にそろえ、書き出すとき eol・設定・OS で CRLF にすることがある。前に CRLF で入っていても、入れるたびに LF にそろえる | （例に *.c text などがある） |
text=auto | Git がテキストかを決める。テキストで、まだ CRLF で Git に入っていなければ、変換する | 「良い既定」と説明 |
-text | 変換をしない | 書かれていない |
eol=lf | 書き出すとき、インデックスと同じ（LF）。text が書かれていなければ text が付く | Windows でも LF のままにしたいファイルに |
eol=crlf | 書き出すとき CRLF | macOS・Linux でも CRLF のままにしたいファイルに |
binary | -diff -merge -text と同じ | -text -diff の別名 |
binary の中身は、Git の文書と GitHub の文書で書き方が違います。手元で *.png binary のファイルに git check-attr -a run.bat img.png hello.txt を流すと、img.png には binary: set・diff: unset・merge: unset・text: unset と出て、Git の文書のほうと合いました。
書き方の例
Git の文書の例は、次の 5 行です。.txt・.vcproj・.sh を変換の対象にし、書き出すとき .vcproj は CRLF、.sh は LF にし、.jpg は中身に関係なく変換しない、という内容です。
* text=auto
*.txt text
*.vcproj text eol=crlf
*.sh text eol=lf
*.jpg -text*.sh text eol=lf の行は、シェルスクリプトを LF のままにしたいときの書き方です。改行が CRLF のシェルスクリプトを Docker で動かした例は、Dockerfile の記事にあります。
手元で、次の 3 行を .gitattributes に書いて試しました（core.autocrlf=true のまま）。*.bat の行は * text=auto eol=lf よりあとにあり、run.bat では eol=crlf が勝ちました。
$ cat -n .gitattributes
1 * text=auto eol=lf
2 *.bat text eol=crlf
3 *.png binary
$ git add .
warning: in the working copy of 'run.bat', LF will be replaced by CRLF the next time Git touches it
$ git commit -q -m first
$ git ls-files --eol
i/lf w/lf attr/text=auto eol=lf .gitattributes
i/lf w/lf attr/text=auto eol=lf hello.txt
i/-text w/-text attr/-text img.png
i/lf w/lf attr/text eol=crlf run.bat
$ rm run.bat img.png
$ git checkout -- run.bat img.png
$ od -c run.bat
0000000 e c h o h i \r \n
0000011
$ od -c img.png
0000000 211 P N G \r \n 032 \n A B \r \n C D \n
0000017run.bat（LF で入れたファイル）には警告が出て、書き出し直すと CRLF になりました。img.png には CRLF のバイトが含まれていますが、警告は出ず、書き出し直しても変わりませんでした。
.gitattributes と core.autocrlf はどちらが効く？
GitHub の文書は、.gitattributes をコミットすると、リポジトリに関わる全員の core.autocrlf の設定より優先される、と書いています。一方、Git の文書（gitattributes）は、text を書いていないファイルは core.autocrlf で決まり、eol を書いていなければ core.autocrlf か core.eol で決まる、と書いています。2 つの文書の言い方は、そのまま重なりません。
手元で、core.autocrlf=true のままにして試した結果です。
* text=autoだけ書いたとき、LF のファイルに警告が出ました（.gitattributes自身にも出ました）* text=auto eol=lfに変えると、LF のファイルには出ず、CRLF のファイル（crlf.txt）には「CRLF will be replaced by LF」が出ました
$ cat .gitattributes
* text=auto
$ git add .gitattributes hello.txt
warning: in the working copy of '.gitattributes', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of 'hello.txt', LF will be replaced by CRLF the next time Git touches it$ cat .gitattributes
* text=auto eol=lf
$ git add .gitattributes hello.txt
$ git add crlf.txt
warning: in the working copy of 'crlf.txt', CRLF will be replaced by LF the next time Git touches it
$ git commit -q -m first
$ git ls-files --eol
i/lf w/lf attr/text=auto eol=lf .gitattributes
i/lf w/crlf attr/text=auto eol=lf crlf.txt
i/lf w/lf attr/text=auto eol=lf hello.txtcrlf.txt は、書き出し直すと LF になりました（od -c で \n）。.gitattributes に書いた分だけが上書きされる、と一文で言い切る文書は見つかっていないので、この記事も言い切りません。
警告が消えないときは？
読者の環境は分からないので、ここでは確かめ方までを書きます。「これで消えます」と言える手順は、一次資料にありません。
- 値と出どころを見ます（Git の文書）。
git config --show-origin core.autocrlfで、リポジトリの設定と全体の設定のどちらにあるかが分かります - ファイルごとに見ます。
git ls-files --eolのattr/は、書き出しやコミットのときに使われる改行の属性です（Git の文書）。空のファイルには、改行の属性（text・eol）が当たっていません * text=autoだけのときは、core.autocrlf=trueのままだと、LF のファイルに警告が出ました（試した結果）。* text=auto eol=lfにすると、LF のファイルには出ませんでした（試した結果）。eolを書かないとcore.autocrlfかcore.eolで決まります（Git の文書）- もう CRLF で入っているファイルは、Git の文書によると、
text=autoでは変換されません（まだ CRLF で入っていないファイルだけが対象です）。手元でも、CRLF で入れたファイルに.gitattributes（* text=auto eol=lf）を足しただけでは、git statusに出ませんでした（試した結果）。「すでに CRLF で入っているファイルをそろえ直すには」の節のgit add --renormalize .へ進みます
すでに CRLF で入っているファイルをそろえ直すには（git add --renormalize）
text=auto は、まだ CRLF で Git に入っていないファイルだけを変換します（Git の文書）。すでに CRLF で入っているファイルは、.gitattributes を足しただけでは変わりません。そろえ直すには git add --renormalize . を使います。Git の文書（git-add）は、追跡中の全部のファイルに、入れるときの変換（clean と呼ばれる処理）をやり直してインデックスに入れ直す、core.autocrlf や text 属性を変えたあとに使う、-u を含む、と説明しています。ひとつだけの CR（CRLF でない CR）は触りません。
手順は、Git の文書（gitattributes）は「きれいな作業ツリー（変更が無い状態）から」、GitHub の文書は「先に git add . -u と git commit」と書いています。順に並べると、次のとおりです。
- 変更をコミットして、変更が無い状態にします
.gitattributesを書きます（Git の文書の例は* text=auto）git add --renormalize .を流しますgit statusで、そろえるファイルを見ますgit commitします
そろえたくないファイルが git status に出たときは、先にそのファイルの text を外します（Git の文書の例は manual.pdf -text）。逆に、Git がテキストと見抜けないファイルには、weirdchars.txt text のように text を付けられます。
手元で、core.autocrlf=false のまま、CRLF の a.txt・b.txt と LF の c.txt をコミットし、* text=auto eol=lf の .gitattributes を足して試した結果です。git add --renormalize . は何も表示せず、そのあとの git status --short に M a.txt のように出ました。コミットしても、作業ツリーのファイルは CRLF のままで、書き出し直すと LF になりました。
$ git ls-files --eol
i/crlf w/crlf attr/ a.txt
i/crlf w/crlf attr/ b.txt
i/lf w/lf attr/ c.txt
$ cat .gitattributes
* text=auto eol=lf
$ git status --short
?? .gitattributes
$ git add --renormalize .
$ git status --short
M a.txt
M b.txt
?? .gitattributes
$ git ls-files --eol
i/lf w/crlf attr/text=auto eol=lf a.txt
i/lf w/crlf attr/text=auto eol=lf b.txt
i/lf w/lf attr/text=auto eol=lf c.txt
$ git add .gitattributes
$ git commit -m "Introduce end-of-line normalization"
[main f36c254] Introduce end-of-line normalization
3 files changed, 4 insertions(+), 3 deletions(-)
create mode 100644 .gitattributes
$ git ls-files --eol
i/lf w/lf attr/text=auto eol=lf .gitattributes
i/lf w/crlf attr/text=auto eol=lf a.txt
i/lf w/crlf attr/text=auto eol=lf b.txt
i/lf w/lf attr/text=auto eol=lf c.txt
$ od -c a.txt
0000000 o n e \r \n t w o \r \n
0000012
$ rm a.txt b.txt
$ git checkout -- a.txt b.txt
$ od -c a.txt
0000000 o n e \n t w o \n
0000010
$ git status --shortGitHub の文書は、.gitattributes をコミットしたり、core.autocrlf を設定したりすると、Git が自動で改行を新しい設定に合わせる、と書いています（英語の原文は "Git automatically changes line endings to match your new configuration"）。手元では、.gitattributes をコミットしても作業ツリーのファイルは CRLF のままで、書き出し直したときに変わりました。警告の文の "the next time Git touches it" とは、手元の結果のほうが合っています。2 つの書き方を並べておきます。
よくある質問
core.autocrlf の既定の値は？
Git 本体の源では、false です。Git の文書（git-config）の core.autocrlf の段落には、既定の値は書かれていません。Git for Windows のインストーラーの源（2026年10月23日に見た版）では、既定で 1 つ目の選択肢（true）が選ばれ、system の設定に書かれます。
text=auto と text の違いは？
Git の文書によると、text は、そのファイルをテキストと決めて、入れるたびに LF にそろえます（前に CRLF で入っていても）。text=auto は、Git がテキストかどうかを決め、テキストで、まだ CRLF で入っていなければ変換します。そうでなければ変換しません。
画像などのバイナリを変換させないには？
Git の文書は、.gitattributes に *.jpg binary のように書くと、text と diff が外れる、と説明しています。GitHub の文書も、バイナリは .gitattributes ではっきり書くよう勧めています。手元で *.png binary を書いたときは、CRLF のバイトがあるファイルでも、警告は出ず、書き出し直しても変わりませんでした（試した結果）。
変換は、まれにデータを壊します。Git の文書（git-config の core.safecrlf）は、テキストと見なされたバイナリは壊れうること、壊れに早く気づけば、.gitattributes で型を決めて直せることを書いています。
core.safecrlf とは？
変換が元に戻せるかを確かめる設定です（Git の文書）。true は、戻せない変換になるファイルを受け付けません。warn は、警告だけで続けます。Git の源では、設定しないときは warn です。手元で true にして git add すると、fatal: で止まりました（試した結果、終了コードは 128 でした）。
core.eol とは？
text と見なしたファイルの作業ツリーの改行を決める設定で、core.autocrlf が true か input のときは無視される、と Git の文書（git-config）にあります。既定の値は native（その OS の改行）です。
まとめ
- 警告は、次に Git がファイルを書き出したときに改行が変わる、という知らせです。
git addは止まりません - 値と出どころは
git config --show-origin core.autocrlf、ファイルごとの改行はgit ls-files --eolで見ます - 改行をリポジトリで決めるなら
.gitattributes。core.autocrlf=trueのままなら、* text=auto eol=lfにすると LF のファイルには警告が出ませんでした（試した結果） - すでに入っているファイルは
git add --renormalize .でそろえ直します - この記事で確かめていないこと: Windows での表示、Git for Windows のどのリリースのインストーラーが今回見た源から作られたか、
git diffでの safecrlf の警告、VS Code・TortoiseGit などの設定、Git LFS
参考資料
- git-config（Git 公式の文書）
- gitattributes（Git 公式の文書）
- git-add（Git 公式の文書）
- git-ls-files（Git 公式の文書）
- Configuring Git to handle line endings（GitHub Docs）
- 警告の文を変えた Git のコミット（GitHub）
- Git 2.37.0 のリリースノート（GitHub）
- 今の警告の文（Git の源 convert.c）
- Git for Windows のインストーラーの源（GitHub）
※この記事は、2026年10月23日時点の公式の資料と照らして確かめています。誤りに気づいたらお問い合わせからお知らせください。
