@hnbcinfo 这个问题可以通过安装 Word 插件解决，我现在用的是「 Writage 」，有了这个工具之后 Word 可以直接保存为 MarkDown，也可以直接查看 MarkDown，基本上实现了互通。

这个软件在之前是免费的，最近的版本是收费的，但其实免费的功能基本上也够了。

还有就是剪藏的问题，可以通过 MaoXian 直接将对应的网页转换成 MarkDown 保存到本地，然后直接可以引用。

我现在写笔记就像写论文似的，几乎所有的语句都是有引用的，这样的话很容易找到出处，知识之间形成了互联，也不容易臆断出错。

@sleeepyy

例如，前段时间对 Git 重新做了地毯式的学习，就完全用的是 Obsidian，效果是很不错的，知识点之间都相互连接起来了，后续查找也非常方便。


@sleeepyy
在学习的时候直接使用 Obsidian 记笔记就自动管理了。

我的很多之前用 MarkDown 写的笔记是不会手动转成 Obsidian 形式的，只有在需要重新查看那些笔记的时候，通过搜索定位到具体段落，然后再转换。

所以说这个管理不是很耗时间，也不是管理「没有的知识」，而是管理当前刚刚学到的。

@shyrock 块引用已经支持了

'兼容'在软件开发中是很重要的

目前看来没有太简洁的方法，git add -A 然后 git ls-files -s 是可以的，不过有可能会破坏当前的状态。

@dreasky git ls-files 并不是单独列出工作树

@dreasky 这分别是列出暂存区和 master，问题是列出工作树

现在看来是文档的问题，和上次一样

@jackiecao 不要钻牛角尖哦，小老弟

@no1xsyzy #4 reflog 是记录 HEAD 的 ref 变更的，所以就算曾经在 stage 中存在过，应该也是找不回来的

问题已解决，谢谢

还有就是 Windows for git 会带有自己的默认 system 和 global config 文件，其中在 gitconfig 中将 autocrlf 设为 true，但这两个文件在 linux 版本中并不存在。

通过 environment.c 查到 enum auto_crlf auto_crlf = AUTO_CRLF_FALSE; 和 int global_conv_flags_eol = CONV_EOL_RNDTRP_WARN; ，从而判断 core.safecrlf 的默认值是 WARN，而 core.autocrlf 的是 FALSE 。

感觉很可能是直接硬编码到代码当中的，不清楚是否判断正确，也不清楚是否有其他的查询接口。

感觉邮件列表上的讨论还是比较轻松的，对于这个不太起眼的 GitHub 的 Pull Request，维护者也发言了，后来我会用邮件列表了，在这里面发了个比较普通的问题，他也是第 1 个回复的，没想到他的时间还挺宽裕的，对于这些问题还来评论评论。

@oaix 原来是这样，其实后面的讨论没来得及看。

可能是因为第 1 次参与这种邮件列表讨论，需要注意的地方太多，花了很长时间才把信息给发出去，感觉很累，后来看到了相关的后续讨论，也就没有兴趣了。

如果不是你提醒的话，还不清楚「存在两个默认值」这个情况。谢谢。

@oaix 你的最初判断是没有错的，的确是文档有问题，我向开发人员提交了 Pull Request，今天收到了邮件通知这个 Pull Request 已经被接受了。

https://cdn.jsdelivr.net/gh/Andy-AO/GitHubPictureBed/img/20210607105156.png

感觉我对这类著名开源项目的可靠性有了过高的估计，很多细节其实有不少的错误，从 Pull Request 列表中就可以看出来。

最后的方案是：
1. 在所有中间仓库文件夹的名称后面加入后缀_ignore
2. 然后使用递归忽略(**/*_ignore)解决问题
实现了基本和老版本等价的效果

@AoEiuV020 #1 其实可以使用 git status -uall