Mercurial internals : 激进权限更改后的 Git 子存储库状态

Question

免责声明：我不是在寻求解决方案、变通方法或任何关于如何做事的建议，我只是对 Mercurial 的内部结构感到好奇。

我有一个 mercurial 存储库，其中包含一些子存储库（Git 和 Mercurial）。

1. 我的存储库和所有子存储库都处于干净状态（即：hg st -S 不返回任何内容）。
2. 我在根目录进行了一些激进的权限更改：chown www-data:www-data -R *

现在，hg st -S 返回已修改的 Git 子存储库的每个文件（Mercurial 子存​​储库仍被视为“干净”）。 hg diff -S -g 的输出为空。我想知道为什么会这样？

到目前为止我发现了什么：

1. 如果我在其中一个子存储库中执行git status，该命令将显示没有待修改，并且此特定存储库不再被hg st 标记为已修改
2. 如果我将权限更改限制为子repo，则只有此子repo 被标记为已修改（即“问题”未链接到.hg 目录中的文件状态）
3. 进行干净更新 (hg up -C) “解决”了问题
4. 如果我仅更改 .git 目录中的权限，则 subrepo 仍被认为是干净的
5. hg --debug up -C 的输出与标记为已修改的 Git 子存储库不同：

“干净” git subrepo：

subrepo/git1: git config --bool core.bare 
subrepo/git1: git rev-parse HEAD
subrepo/git1: git diff-index --quiet HEAD

“修改”git subrepo：

subrepo/git2: git config --bool core.bare
subrepo/git2: git rev-parse HEAD
subrepo/git2: git diff-index --quiet HEAD
  subrepo subrepo/git2: other changed, get git://github.com/XXXX/YYYY.git:6f2442d36bb44724af116b97c85d2e344fc9a0a2:git
subrepo/git2: git cat-file -e 6f2442d36bb44724af116b97c85d2e344fc9a0a2
subrepo/git2: git config --bool core.bare
subrepo/git2: git rev-parse HEAD
subrepo/git2: git reset HEAD
subrepo/git2: git reset --hard HEAD

所以，据我所知，元数据中的权限更改不是这里的原因，那是什么？我可能只是错过了一些非常简单的东西。

仅供参考，我使用的是 1.9.3 版本，我不记得我是否在以前的版本上发表过相同的评论。

在有人提议我停止这样的权限更改之前，我已经这样做了，我不再面临这个问题，只是我想了解为什么会发生一些事情;)

更新

运行 git diff-index HEAD 给出以下输出：

[...]
:100644 100644 fef0f187a5eabc82dc1a90661bd86d317114e40e 0000000000000000000000000000000000000000 M      my/file/insubrepo.php
[...]

如果我运行git diff-index -p HEAD，则差异为空。我仍然不知道为什么 git 认为这些文件被修改了。

Answer 1

可能的问题（有潜在的解决方案）：

更改文件模式将更改与 Git 索引相关的文件统计信息（如 here 所述）。

要纠正问题，请尝试：

1. 导航到您的 Git sburepo
2. 运行git update-index --refresh

这应该可以修复文件状态变脏的问题。

---

Mercurial 内部的背景信息：

要确定 Git 子存储库是否脏（即有本地修改），Mercurial 运行 git diff-index --quiet HEAD。

参见subrepos.py::gitsubrepo的dirty方法。

我希望在您更改权限后，git diff-index 会显示您手动执行 git status 不会显示的更改。

git diff-index的输出格式如下（详见man page）：

:<mode before> <mode after> <status> <file>

鉴于您上面列出的输出，这表示：“文件my/file/insubrepo.php 已在工作副本中修改，但文件模式相同”。