Внутренности Mercurial: состояние подрепозитория Git после агрессивного изменения разрешений

Отказ от ответственности: я не прошу решения, обходного пути или каких-либо советов о том, как что-то делать, мне просто любопытно узнать о внутренностях 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. Если я ограничу изменения разрешений субрепозиторием, только это субрепозиторий будет помечено как измененное (т. е. «проблема» не связана с состоянием файла в каталоге .hg)
  3. Выполнение чистого обновления (hg up -C) «решает» проблему
  4. Если я изменю разрешение только в каталоге .git, подрепозиторий по-прежнему будет считаться чистым.
  5. Вывод hg --debug up -C отличается для подрепозитория Git, помеченного как измененный:

«чистый» репозиторий git:

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, diff пуст. Я до сих пор понятия не имею, почему git считает эти файлы измененными.


git internals mercurial mercurial-subrepos
person krtek    schedule 17.11.2011    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Вероятная проблема (с возможным решением):

Изменение режима файла изменит статистику файла по отношению к индексу Git (как указано здесь).

Чтобы исправить проблему, попробуйте:

  1. Переход к Git sburepo
  2. Выполнить git update-index --refresh

Это должно исправить грязную статистику файла.

Справочная информация о внутреннем устройстве Mercurial:

Чтобы определить, является ли подрепозиторий Git грязным (т. е. имеет ли он локальные модификации), Mercurial запускает git diff-index --quiet HEAD.

См. dirty метод subrepos.py::gitsubrepo.

Я ожидаю, что после того, как вы измените разрешения, git diff-index покажет изменения, которых нет при ручном выполнении git status.

Вывод git diff-index форматируется следующим образом (см. справочную страницу для подробности):

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

Учитывая вывод, который вы указали выше, это говорит о том, что: «Файл my/file/insubrepo.php был изменен в рабочей копии, но режим файла тот же».

person Tim Henigan    schedule 17.11.2011
comment
git diff-index HEAD показывают некоторые изменения, но я не могу понять, что они означают... Я обновил вопрос снимком - person krtek; 18.11.2011
comment
Спасибо за исследование, которое вы вложили в это :) Моя потребность знать удовлетворена! - person krtek; 18.11.2011