当core.autocrlf设为false时，git config设置core.eol的作用是什么？

我看不懂Git相关文档里关于行尾配置的内容，根据git-config(1)文档：

core.eol
为标记为文本的文件（设置了text属性，或text=auto且Git自动检测为文本）设置工作目录中使用的行尾类型。可选值为lf、crlf和native（使用平台原生行尾），默认值为native。更多行尾转换信息见gitattributes[5]。注意若core.autocrlf设为true或input，该值会被忽略。

以及gitattributes(5)文档：

eol
该属性标记路径在检出时使用特定行尾样式，仅当设置了text或text=auto时生效；若未设置text，指定eol会自动设置text。
设为字符串值"crlf"
此设置会在检出文件时将工作目录中的文件行尾转换为CRLF。
设为字符串值"lf"
此设置会在检出文件时使工作目录中的行尾与索引中的保持一致。
未指定
若文件未指定eol属性，其工作目录中的行尾由core.autocrlf或core.eol配置变量决定；若设置了text但未配置这两个变量，Windows平台默认eol=crlf，其他平台默认eol=lf。

我不清楚“设置工作目录中使用的行尾类型”或“标记路径在检出时使用特定行尾样式”的含义，以及这会如何影响Git的行为。另外，既然“若core.autocrlf设为true或input，该值会被忽略”，说明仅当core.autocrlf = false时该配置才相关，但资料显示core.autocrlf = false会让Git完全不更改行尾，原样检出和提交文件，那设置core.eol的意义是什么？

一、行尾配置的含义及Git行为影响 #

• “设置工作目录中使用的行尾类型”/“标记路径在检出时使用特定行尾样式”：本质是Git将仓库索引里的文件提取到本地工作目录时，会把文本文件的换行符转换成你指定的格式。
  • 比如设置core.eol=crlf，或在.gitattributes里给某文件指定eol=crlf，Git检出该文件到工作目录时，会统一把换行符改成CRLF（Windows系统常用格式）。
  • 若设为eol=lf，则工作目录里的文件换行符会和Git索引中的保持一致（Git仓库内部默认用LF存储文本文件）。
• 注意：这个转换只针对文本文件——要么手动设置了text属性，要么text=auto且Git自动识别为文本的文件，二进制文件（如图片、压缩包）不会触发行尾转换。

二、core.eol在core.autocrlf=false时的作用 #

你提到的“core.autocrlf=false让Git完全不更改行尾”是个误解，准确来说：core.autocrlf=false是关闭全局自动双向转换规则（比如提交时强制转LF、检出时强制转CRLF这种全局行为），但Git依然会遵守针对文本文件的core.eol或.gitattributes中的eol配置。

举几个实际场景：

• Windows环境下，core.autocrlf=false但设置core.eol=lf：Git检出文本文件时，会把工作目录里的文件换行符统一改成LF，而非Windows默认的CRLF；提交时只要工作目录里的文本文件是LF，就原样提交，不会做转换。
• Linux环境下，core.autocrlf=false但设置core.eol=crlf：Git检出文本文件时会转换成CRLF，满足你可能需要的Windows格式需求。
• 若未设置core.eol，core.autocrlf=false时Git会采用平台默认行尾：Windows默认CRLF，Linux/macOS默认LF。

简言之：core.autocrlf=false是关闭全局自动转换，而core.eol是给文本文件指定检出到工作目录时的行尾格式，二者作用范围不同，完全可以配合使用。

内容的提问来源于stack exchange，提问作者ban_javascript