core.autocrlf 选项core.autocrlf 的方案）core.autocrlf 的方案）根源是obsidian这个老六默认并且写死了，所有的md文件的换行符都必须是LF，如果不是，那么在下一次进入编辑状态（即使一字不改）时强行改成LF。
反过来，如果你是Windows环境，git一般配置为自动CRLF，也就是不管远端是啥（一般是LF），本地都给你转换成CRLF。这与大多数的本地软件匹配，但obsidian不在其中。这个行为当然可以改，但全局设定改起来不知道哪天就坑到自己，局部环境改起来每次都要操作。
关键是，即使用git config core.autocrlf false改了，每一次点击之后，obsidian的git插件依然给你报更改，必须得再add之后，这个更改信息才会自己消失——用来做操作归集追踪倒是不错。
简而言之，忍不了。
这个跟方案没有强关联，主要都是在 .gitattributes 里面操作而已，并且对于有大量附件的仓库（像我放了六千多个，加起来十几个G的Office文档等），LFS确实是个好东西。
启用LFS的步骤到处都是，这里不详述。按正常步骤操作完了之后，git仓库根目录下有一个.gitattributes文件。
在.gitattributes文件的头部添加下面几行（如果你还没有就新建一个）：
#换行符问题
* text=auto
* text eol=lf
*.bat text eol=crlf
*.ps1 text eol=crlf
后面两行是因为我有一些bat和ps1格式的附件，没有的不用添加。
然后，commit一下，因为必须是提交过（至少是add）过的.gitattributes文件，git才遵从。
这样完了之后，git在检出新文件时应该就自动把换行符转换成LF了，但已经检出的旧文件是不会主动更改的。
也就是说，下面的步骤如果你搞不定，理论上可以用删掉重新克隆的办法完成所有操作。
此时，所有以往的MD文件现在仍然是CRLF，可以用下面的方法自动转换：
首先，git status查看是否有更改，如果有bat一类的文件，现在可能显示已经更改。这个不用理他，但如果stage区域有文件，用git restore --staged确保他们不再暂存区。
然后，git rm --cached -r .，这个命令将所有文件从暂存区中移除，并使其看起来像刚从仓库克隆下来一样。
最后，执行git reset --hard，我理解是相当于重新克隆了一遍，使其与 .gitattributes 文件中定义的新换行符格式匹配。
此处点名批评
千问3，让我git add --renormalize .，实际上不起作用。
这个过程会疯狂读写磁盘，稍等一下，完成后，磁盘上的MD文件应该都变成LF换行符了，并且也没有产生一次包括所有文件所有行的巨型更改。并且，无论这个仓库克隆到哪里，行为都是一致的，这意味着这个办法不仅仅是对obsidian这个老六有效，而是可以用于所有需要固定换行符的仓库。
今天尝试了换机器直接拷贝文件库而不是重新克隆，结果是有两个文件又莫名其妙陷入了全部更改状态，restore什么的也无效。
最后，重新执行了一遍git rm --cached -r .和git reset --hard，消停了。