从 PS1 提示符运行 git update-index --refresh 安全吗？

Question

我一直在研究检查存储库中更改以更新 PS1 提示的最快方法。由于不值得详述的原因，无法访问 __git_ps1() 宏，而且无论如何其他帖子都建议了各种命令，包括 __git_ps1() 中使用的命令。

原因：我正在通过 VPN 和 ssh 访问远程服务器上的存储库，远程存储库通过我与我们内部 git 服务器的连接返回。我猜（但真的不确定这是否属实）这可能是在新的一天建立新连接时，cd 到此远程服务器上的 repo 可能导致 git ls-files -m 占用 3 或 4几秒钟内完成，在文件缓存有帮助后仍需要长达 1 秒钟。

为了改进这一点，我发现git diff-index --quiet HEAD 几乎是即时的，但第二天它开始返回“1”，即使实际上没有任何变化（git status 运行非常缓慢，没有输出）。我发现git update-index --refresh -q 似乎（很快）解决了这个问题，如果实际上没有任何变化，它也会返回“0”。

根据我的阅读，我认为从 PS1 提示符下运行应该是安全的，但我知道这是一个“较低级别”的 git 命令，我可能无法理解所有含义。因此，需要明确的是，我目前有以下内容来检查更改，这似乎总是很快，但是一天后开始在干净的存储库中输出“*”。

if git diff-index --quiet HEAD 2>/dev/null && [[ -z "$(git ls-files --others --exclude-standard --directory --no-empty-directory)" ]]
    then echo -n " "
    else echo -n " *"
fi

任何“git 大师”都可以看到将第一个测试更改为 git update-index --refresh -q 的问题吗？

Answer 1

它应该可以工作，除非在Git LFS (Large File Storage) 中使用，因为explained here，它可以触发活泼的时间戳。

这就是为什么在 Git 2.36（2022 年第二季度）中，“git update-index --refresh”^(man) 被教导如何更好地处理不恰当的时间戳（就像“git status”(man) 已经这样做了。

参见Marc Strapetz (mstrap)@commit 2ede073、commit 9b71efd、commit 0275e4d、commit ab6245b（2022 年 1 月 7 日）。
^{（由 Junio C Hamano -- gitster -- 合并到 commit ee52b35，2022 年 2 月 5 日）}

update-index: 刷新应该重写索引，以防出现不恰当的时间戳

^{签字人：Marc Strapetz}

'git update-index --refresh'^(man) 和 '--really-refresh' 应该在遇到 racy 时间戳时强制写入索引文件，如 'git status'^(man)already does.

请注意，调用 'git update-index --refresh' 仍然不能保证之后不会有更多的时间戳（'git status' 也是如此）： - 在触摸并添加一个之后立即调用 'git update-index --refresh'如果所有三个操作都在 racy-tolerance 范围内发生（通常为 1 秒，除非 USE_NSEC 已定义），文件可能仍会留下活泼的时间戳 - 为设置在未来的时间戳调用 'git update-index --refresh' 会使它们变得活泼

要确保解决此类异常时间戳，需要等到系统时钟超过这些时间戳，然后才写入索引文件。
特别是对于未来的时间戳，这似乎不可行，因为可能会出现长时间的延迟/挂起。