git - 从 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 命令，我可能不理解所有的含义。所以，要清楚，我目前有以下检查更改，这似乎总是很快，但一天后开始在干净的 repo 中输出“*”。

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 年第 2 季度)中，"git update-index --refresh "^{( man )} 被教导更好地处理活泼的时间戳(就像 "git status "< sup>( man ) 已经这样做了)。

参见 commit 2ede073 , commit 9b71efd , commit 0275e4d , commit ab6245b (2022 年 1 月 7 日)Marc Strapetz (mstrap) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit ee52b35 ，2022 年 2 月 5 日)}

update-index: refresh should rewrite index in case of racy timestamps

^{Signed-off-by: Marc Strapetz}

'git update-index --refresh'^(man) and '--really-refresh' should force writing of the index file if racy timestamps have been encountered, as 'git status'^(man) already does.

Note that calling 'git update-index --refresh' still does not guarantee that there will be no more racy timestamps afterwards (the same holds true for 'git status'): - calling 'git update-index --refresh' immediately after touching and adding a file may still leave racy timestamps if all three operations occur within the racy-tolerance (usually 1 second unless USE_NSEC has been defined) - calling 'git update-index --refresh' for timestamps which are set into the future will leave them racy

To guarantee that such racy timestamps will be resolved would require to wait until the system clock has passed beyond these timestamps and only then write the index file.
Especially for future timestamps, this does not seem feasible because of possibly long delays/hangs.