#git #netapp #git-index
Вопрос:
Мой вариант использования заключается в том, что
- У меня есть очень большой репозиторий GIT, созданный uidA:gidA, со всеми его файлами и индексом git как uidA:gidA
- Что я сделал снимок/заморозил с помощью технологии файловой системы netapp, то есть заморозил содержимое этого каталога и рабочей области git
- Я «клонирую файловую систему» моментального снимка для uidB:gidB. который мгновенно создает новое рабочее пространство с точной копией снимка, с разницей в 1, каждый файл/каталог теперь принадлежит uidB:gidB.
Когда я выполняю «статус git», это приводит к обновлению индекса, скорее всего, потому, что файлы/объекты в индексе хранятся как uidA:gidA, в то время как все файлы в рабочей области «клонированная файловая система» принадлежат uidB:gidB и существует несоответствие.
- Есть ли способ эффективно обновить некоторые или все объекты/файлы в индексе до uidB:gidB. Я подозреваю, что обновление по умолчанию фактически проверяет каждый файл перед обновлением индекса, что в данном случае не требуется. Поэтому я хочу слепо обновить все файлы в индексе до uidB:gidB
- ИЛИ избегайте принудительного обновления индекса.
Обновление индекса в нашей очень большой рабочей области занимает более 20 минут в NFS. Объем рабочего пространства составляет 800 ГБ
Комментарии:
1.Git ничего не делает с uid, gid и т. Д.; Он понимает, в очень ограниченной степени, как манипулировать umask, но это все. По какой-то причине индекс хранит пару uid/gid, но Git ничего не делает, кроме как сравнивает их. Похоже, что он даже не должен их хранить (и, следовательно, не сравнивать). Вероятно, вы могли бы написать программу для чтения и записи сохраненных пар uid/gid, но в источнике Git ее нет.
Ответ №1:
Инструменты командной строки Git не позволяют обновлять эту информацию в индексе. Однако Git предоставляет опции для управления тем, какие данные хранятся в индексе.
Вы можете установить core.checkstat
minimal
значение, чтобы исключить из индекса множество данных, включая UID, GID, номер устройства и номер индекса. Обычно это включено, потому что это хороший способ быстро обнаружить изменения, но в вашем случае вы этого не хотите. Вам также может потребоваться установить core.trustCtime
false
значение, если ваша операция копирования также не сохраняет ctime.
Однако обратите внимание, что совместное использование рабочего дерева пользователями небезопасно. Любой пользователь, который может изменить исходное рабочее дерево, может выполнять произвольный код, как и другие пользователи, использующие рабочее дерево или его копию, путем настройки конфигурации. Таким образом, это возможно сделать, но это небезопасно, если вы не доверяете первоначальному создателю рабочего дерева для выполнения произвольного кода на вашей машине. Единственная безопасная вещь, которую можно сделать с ненадежным хранилищем, — это клонировать или извлекать из него.