(这不是 How does git detect that a file has been modified? 的副本,因为我问的是 Windows,引用的 QA 提到了 stat
和 lstat
,它们不适用于 Windows) .
对于像 SVN 和 TFS 这样的传统系统,“状态数据库”需要明确地手动通知本地工作区中文件的任何更改:默认情况下文件是只读的,因此您不会不小心做出更改首先明确通知您的 SVN/TFS 客户端。幸运的是,IDE 集成意味着导致文件添加、修改、删除和重命名(即“ checkout ”)的操作可以自动传递给客户端。这也意味着您需要像 TortoiseSVN 这样的工具来处理 Windows 资源管理器中的文件,以免您的更改被忽略 - 并且您应该定期运行通常很长的服务器到本地比较扫描以检测任何更改。
但是 Git 没有这个问题——在我的 Windows 机器上,我可以有一个 GB 大小的存储库,其中包含数十万个文件,深度很多,但是如果我对嵌套非常深的文件进行 1 字节的更改,我可以看到 Git 在运行 git status
后知道了。这是奇怪的部分——因为 git 不使用任何守护进程或后台任务——运行 git status
也不涉及任何我能看到的重要 IO 事件,我立即得到结果,它确实不要翻动我的磁盘来搜索我所做的更改。
此外,Git GUI 工具(例如 Git 与 Visual Studio 2015 的集成)也有一定的魔力——我可以在记事本或其他程序中进行更改,VS 的 Git Changes 窗口会立即将其提取出来。 VS 可以简单地使用 ReadDirectoryChanges
(FileSystemWatcher
) - 但是当我在 Process Explorer 中查看 devenv
进程时,我没有看到任何相应的句柄,但这也没有解释 git status
如何看到更改。
最佳答案
Git 对记录在索引中的每个文件运行 POSIX-y lstat(2)
调用的 Windows 等价物,以首先确定文件是否被修改。它将从该信息中获取的修改时间和大小与索引中为该文件记录的值进行比较。
此操作在 NTFS(和网络映射驱动器)上非常慢,因此自从一段时间以来,Git for Windows 获得了一个特殊的调整,由 core.fscache
configuration option 控制在大约 2 或 3 个 GfW 版本之前默认启用。我不知道确切的细节,但它会尽量减少 Git 需要 lstat(2)
您的文件的次数。
IIUC,core.fscache
启用的机制没有使用文件系统监视 Win32 API,因为 Git 在您的系统上没有运行守护进程/服务;所以它只是优化了 Git 向文件系统层询问有关跟踪文件的统计信息的方式。
关于windows - git 如何在 Windows 上检测修改过的文件?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37398571/