Tob*_*obu 37
Git努力从单独的lstat()值确信工作树与索引匹配,因为回退文件内容非常昂贵.
Documentation/technical/racy-git.txt描述了使用的统计字段,以及如何避免由于低mtime粒度导致的某些竞争条件.本文有更多细节.
stat值不是防篡改的,参见futimens(3).Git可能会被愚弄而错过对文件的更改; 这不会影响内容散列的完整性.
对于像"git status"这样的报告有一个初始的mtime检查,但是当计算最终提交时,mtimes并不重要......这是重要的SHA1.
好吧，我很可能会猜到它正在使用多个stat()调用组合来确定可能已更改的内容，然后实际上是试图确定是否使用了差异引擎。
您可以在此处查看diff引擎的代码以了解一些想法。我在代码库中进行了跟踪，以确保status命令确实调用了此代码（看起来很多东西！），实际上，当您知道Git在Windows上的性能很差时，所有这些都非常有意义。它正在使用仿真层来执行这些POSIX类型调用：git status在该平台上执行操作要慢一个数量级。
无论如何，只要从头到尾阅读所有代码（如果有时间，我可能以后再说！），这就是我目前可以接受的范围……如果有人使用该代码库，也许可以说是更加确定的。
注意：另一个可能的加速来自明智地使用inline函数，在明显有意义的地方，您可以在标题中清楚地看到这一点。
[编辑：看到这里的的解释stat()]