Причина, по которой существуют упакованные ссылки, заключается в том, чтобы ускорить доступ в репо с миллионами ссылок - проще посмотреть на один файл с несколькими строками, чем попасть в файловую систему один раз для каждой ссылки.Все, что нужно знать о refs в git, проходит через код, который может читать как каталог refs, так и упакованный файл refs.Распаковка его уничтожит его цель.Если вы хотите получить доступ к ссылкам, используйте сантехнические команды (например, show-ref, for-each-ref, update-ref ...).Я не могу придумать какой-либо вид доступа, который был бы быстрее и проще с структурой каталогов, чем с сантехническими командами (особенно с доступным для каждого ссылки).
И да, упакованные объекты (как упакованные ссылки) создан для улучшения производительности, но есть огромная разница.Упакованный файл ссылок - это просто набор независимых строк.Вы можете, по сути, бесплатно, добавить или удалить из него.Там нет необходимости распаковывать его, чтобы изменить его.Упакованные объекты, с другой стороны, являются дельта-сжатыми, поэтому объекты внутри зависят друг от друга.Они значительно сокращают использование диска, и объекты могут быть прочитаны с них по разумной цене, но попытка изменить набор объектов в пакете намного дороже, чем модификация незакрепленных объектов, поэтому это делается только периодически git repack (вызывается git gc), хотя я не верю, git repack на самом деле распаковывает объекты - он просто читает их из файла пакета, упаковывает их вместе с незакрепленными и создает новый пакет.
Однако, когда пакетпереносится с пульта, распаковывается с локальной стороны.Я вижу вызов метода unpack в источнике git receive-pack, а на справочной странице pack-objects написано:
Команда git unpack-objects может прочитать упакованный архив и развернуть объекты, содержащиеся вупаковать в формате «один файл - один объект»;Обычно это делается командами smart-pull, когда пакет создается «на лету» для эффективной передачи по сети их партнерами.