Где "git update-index -assume-неизменный файл" фактически сохраняет эту информацию?

Ответ 1

В нем говорится, где в команде - git update-index

Таким образом, вы не можете редактировать индекс, так как это не текстовый файл.

Кроме того, чтобы подробнее рассказать о том, что хранится с помощью команды git update-index --assume-unchanged, см. раздел Using "assume unchanged" bit в руководстве

Ответ 2

Как говорили другие, он хранится в индексе, который находится в .git/index.

После некоторой детективной работы я обнаружил, что она расположена по адресу: считать допустимым бит каждой записи индекса.

Поэтому, прежде чем понимать, что следует, вы должны сначала понять глобальный формат индекса, как объяснено в моем другом ответе.

Далее я объясню, как я подтвердил, что бит "предположим" является виновником:

• эмпирически
• прочитав источник

Эмпирические

Время hd.

Настройка:

git init
echo a > b
git add b

Тогда:

hd .git/index

дает:

00000000  44 49 52 43 00 00 00 02  00 00 00 01 54 e9 b6 f3  |DIRC........T...|
00000010  2d 4f e1 2f 54 e9 b6 f3  2d 4f e1 2f 00 00 08 05  |-O./T...-O./....|
00000020  00 de 32 ff 00 00 81 a4  00 00 03 e8 00 00 03 e8  |..2.............|
00000030  00 00 00 00 e6 9d e2 9b  b2 d1 d6 43 4b 8b 29 ae  |...........CK.).|
00000040  77 5a d8 c2 e4 8c 53 91  00 01 62 00 c9 a2 4b c1  |wZ....S...b...K.|
00000050  23 00 1e 32 53 3c 51 5d  d5 cb 1a b4 43 18 ad 8c  |#..2S<Q]....C...|
00000060

Сейчас:

git update-index --assume-unchanged b
hd .git/index

дает:

00000000  44 49 52 43 00 00 00 02  00 00 00 01 54 e9 b6 f3  |DIRC........T...|
00000010  2d 4f e1 2f 54 e9 b6 f3  2d 4f e1 2f 00 00 08 05  |-O./T...-O./....|
00000020  00 de 32 ff 00 00 81 a4  00 00 03 e8 00 00 03 e8  |..2.............|
00000030  00 00 00 00 e6 9d e2 9b  b2 d1 d6 43 4b 8b 29 ae  |...........CK.).|
00000040  77 5a d8 c2 e4 8c 53 91  80 01 62 00 17 08 a8 58  |wZ....S...b....X|
00000050  f7 c5 b3 e1 7d 47 ac a2  88 d9 66 c7 5c 2f 74 d7  |....}G....f.\/t.|
00000060

Сравнивая два индекса и глядя на глобальную структуру индекса, см., что единственными отличиями являются:

• число байтов 0x48 (9-я строка 40) изменено с 00 на 80. Это - наш флаг, первый бит флагов ввода кэша.
• 20 байтов от 0x4C до 0x5F. Это ожидается, так как это SHA-1 по всему индексу.

Это также связано с тем, что SHA-1 записи индекса в байтах от 0x34 до 0x47 не учитывает флаги, поскольку он не изменился между обоими индексами. Вероятно, именно поэтому флаги размещаются после SHA, который учитывает только то, что приходит перед ним.

Исходный код

Теперь посмотрим, согласуется ли это с исходным кодом Git 2.3.

Сначала посмотрите на источник update-index, grep assume-unchanged.

Это приведет к следующей строке:

{OPTION_SET_INT, 0, "assume-unchanged", &mark_valid_only, NULL,
  N_("mark files as \"not changing\""),
  PARSE_OPT_NOARG | PARSE_OPT_NONEG, NULL, MARK_FLAG},
{OPTION_SET_INT, 0, "no-assume-unchanged", &mark_valid_only, NULL,
  N_("clear assumed-unchanged bit"),
  PARSE_OPT_NOARG | PARSE_OPT_NONEG, NULL, UNMARK_FLAG},

поэтому значение сохраняется в mark_valid_only. Grep, и найдите, что он используется только в одном месте:

if (mark_valid_only) {
  if (mark_ce_flags(path, CE_VALID, mark_valid_only == MARK_FLAG))
    die("Unable to mark file %s", path);
  return;
}

CE означает запись в кэш.

При быстром просмотре mark_ce_flags мы видим, что:

if (mark)
  active_cache[pos]->ce_flags |= flag;
else
  active_cache[pos]->ce_flags &= ~flag;

Таким образом, функция в основном устанавливает или выводит бит CE_VALID, в зависимости от mark_valid_only, который является трехступенчатым:

• mark: --assume-unchanged
• unmark: --no-assume-unchanged
• ничего не делать: значение по умолчанию 0 параметра, установленного в {OPTION_SET_INT, 0

Далее, по grepping в builtin/, мы видим, что никакое другое место не устанавливает значение CE_VALID, поэтому --assume-unchanged должна быть единственной командой, которая его устанавливает.

Однако флаг используется во многих местах исходного кода, что следует ожидать, поскольку оно имеет много побочных эффектов, и оно используется каждый раз, например:

ce->ce_flags & CE_VALID

поэтому мы заключаем, что он является частью поля ce_flags struct cache_entry.

Индекс указан в cache.h, потому что одна из его функций - это кеш для быстрого создания коммит.

Изучая определение CE_VALID под cache.h и окружающие линии, мы имеем:

#define CE_STAGEMASK (0x3000)
#define CE_EXTENDED (0x4000)
#define CE_VALID (0x8000)
#define CE_STAGESHIFT 12

Итак, мы заключаем, что это самый первый бит этого целого числа (0x8000), рядом с CE_EXTENDED, который является когерентным с моим предыдущим экспериментом.