Как Git обрабатывает символические ссылки?

Git просто сохраняет содержимое ссылки (то есть путь к объекту файловой системы, на который она ссылается) в виде «большого двоичного объекта», как это было бы для обычного файла. Затем он сохраняет имя, режим и тип (включая тот факт, что это символическая ссылка) в объекте дерева, который представляет его содержащий каталог.

Когда вы проверяете дерево, содержащее ссылку, оно восстанавливает объект как символическую ссылку независимо от того, существует ли целевой объект файловой системы или нет.

Если вы удалите файл, на который ссылается символическая ссылка, это никак не повлияет на символическую ссылку, управляемую Git. У вас будет свисающая ссылка. Пользователь может удалить или изменить ссылку, чтобы указать на что-то действительное, если это необходимо.

Вы можете узнать, что Git делает с символической ссылкой, посмотрев, что она делает, когда вы добавляете ее в индекс. Индекс похож на предварительную фиксацию. Когда индекс зафиксирован, вы можете использовать git checkout, чтобы вернуть все, что было в индексе, в рабочий каталог. Итак, что делает Git, когда вы добавляете символическую ссылку в индекс?

Сначала сделайте символическую ссылку:

$ ln -s /path/referenced/by/symlink symlink

Git еще не знает об этом файле. git ls-files позволяет проверять ваш индекс (-s выводит результат, похожий на stat):

$ git ls-files -s ./symlink
[nothing]

Теперь добавьте символьную ссылку в индекс. Когда вы добавляете файл в индекс, Git копирует его содержимое в хранилище объектов.

$ git add ./symlink

Итак, что было добавлено?

$ git ls-files -s ./symlink
120000 1596f9db1b9610f238b78dd168ae33faa2dec15c 0       symlink

Хеш - это ссылка на упакованный объект, созданный в хранилище объектов. Вы можете изучить этот объект, если посмотрите .git/objects/15/96f9db1b9610f238b78dd168ae33faa2dec15c в корне вашего репозитория. Это файл, который Git хранит в репозитории, который вы можете позже получить. Если вы изучите этот файл, вы увидите, что он очень маленький. Он не сохраняет содержимое связанного файла. Чтобы убедиться в этом, распечатайте содержимое упакованного объекта репозитория с помощью git cat-file:

$ git cat-file -p 1596f9db1b9610f238b78dd168ae33faa2dec15c
/path/referenced/by/symlink

(Примечание 120000 - это режим, указанный в ls-files выводе. Это будет что-то вроде 100644 для обычного файла.)

Но что Git делает с этим объектом, когда вы извлекаете его из репозитория в свою файловую систему? Это зависит от конфигурации core.symlinks. Из man git-config:

core.symlinks

Если false, символические ссылки извлекаются как небольшие простые файлы, содержащие текст ссылки.

Итак, с символической ссылкой в ​​репозитории при оформлении заказа вы получаете либо текстовый файл со ссылкой на полный путь к файловой системе, либо правильную символическую ссылку, в зависимости от значения core.symlinks config.

В любом случае содержимое пути, на который указывает символическая ссылка, не сохраняется в репозитории (если, конечно, указанный путь также находится в репозитории).

Примечание редактора: это сообщение может содержать устаревшую информацию. См. Комментарии и этот вопрос относительно изменений в Git с версии 1.6. .1.

Символьные каталоги:

Важно отметить, что происходит, когда есть каталог, который является мягкой ссылкой. Любой запрос Git с обновлением удаляет ссылку и делает ее обычным каталогом. Это то, чему я научился на собственном горьком опыте. Некоторые идеи можно найти здесь и здесь.

Пример

До

 ls -l
 lrwxrwxrwx 1 admin adm   29 Sep 30 15:28 src/somedir -> /mnt/somedir

git add/commit/push

It remains the same

После git pull И найдено несколько обновлений

 drwxrwsr-x 2 admin adm 4096 Oct  2 05:54 src/somedir

Особый случай: когда git checkout ^(man) удаляет путь, которого нет в проверяемом коммите Out, это было недостаточно осторожно, чтобы не переходить по символическим ссылкам, что было исправлено в Git 2.32 (второй квартал 2021 года).

См. фиксацию fab78a0, commit 462b4e8 (18 марта 2021 г.) от (matheustavares).
^{(Объединено Junio ​​C Hamano - gitster - в commit 9210c68, 30 марта 2021 г.)}

checkout: не следуйте символическим ссылкам при удалении записей

^{Подписано: Матеус Таварес}

На странице 1d718a5 (не перезаписывайте неотслеживаемые символические ссылки, 2011-02-20, Git v1. 7.5-rc0 - слияние), symlink.c: check_leading_path () начал возвращать разные коды для FL_ENOENT и FL_SYMLINK.
Но один из его вызывающих, unlink_entry(), не был настроен на это изменение, поэтому он начал следовать символическим ссылкам на ведущем пути к подлежащим удалению записям.
Исправьте это и добавьте регрессионный тест.

И поскольку мы больше не пытаемся разъединить такие пути, мы также не получаем предупреждения от remove_or_warn().

Для обычных файлов и символических ссылок сомнительно, было ли предупреждение вообще полезно: unlink_entry() удаляет отслеживаемые пути, которые больше не должны присутствовать в состоянии, в котором мы проверяем.
Если бы путь имел свой ведущий каталог заменено другим файлом, это означает, что базовое имя уже не существует, поэтому нет необходимости в предупреждении.
Конечно, мы оставляем обычный файл или символическую ссылку в пути к имени каталога, но этот файл либо не отслеживается сейчас (так что опять же, не нужно предупреждать), или он будет заменен отслеживаемым файлом на следующем этапе этой проверки