Ответ 1
Два ответа до сих пор (в то время, когда я писал это, теперь их больше) правильны в том, что они говорят, но на самом деле не отвечают на вопрос "почему" . Конечно, вопрос "почему" действительно трудно ответить, за исключением авторов различных бит Git (и даже тогда, что, если два частых вкладчика Git дали два разных ответа?).
Тем не менее, учитывая Git "философию", как правило, различные протоколы передачи работают, именовая ссылку. Если они предоставляют SHA-1, это SHA-1 этой ссылки. Для тех, у кого еще нет прямого (например, командной строки) доступа к репозиторию, ни один 1 встроенных команд не позволяет ссылаться на фиксации по идентификатору. Самое близкое, что я могу найти по этой причине, - и это действительно хорошая причина. 2 - этот бит в git upload-archive:
Безопасность
Чтобы защитить конфиденциальность объектов, которые были удалены из история, но может еще не быть обрезанной, git -upload-archive избегает обслуживающие архивы для коммитов и деревьев, которые недоступны из репозиторий refs. Однако, поскольку вычисление достижимости объекта вычислительно дорого, git -upload-archive реализует более строгий, но более простой для проверки набор правил...
Однако он продолжает:
Если параметр конфигурации
uploadArchive.allowUnreachableравен true, эти правила игнорируются, а клиенты могут использовать произвольные выражения sha1. Эта полезно, если вы не заботитесь о конфиденциальности недоступных объектов, или если ваша база данных объектов уже общедоступна для доступа через не смарт-клиента.
что особенно интересно, поскольку git clone получает все доступные объекты в первую очередь, после чего ваш локальный клон может тривиально проверить фиксацию с помощью идентификатора SHA-1 (и создать имя локальной ветки, указывающее на этот идентификатор, если это необходимо, или просто оставите свой клон в режиме "отсоединенный HEAD" ).
Учитывая эти два перекрестных тока, я думаю, что настоящий ответ на вопрос "почему" на данный момент "никто не заботится о том, чтобы его добавить".:-) Аргумент конфиденциальности действителен, но нет причин, чтобы git clone не смог проверить фиксацию по идентификатору после клонирования, так же, как может быть сказано, чтобы проверить какую-либо ветвь, отличную от master 3 с git clone -b .... Единственным недостатком разрешения -b sha1 является то, что Git не может проверять фронт (до начала процесса клонирования), будет ли получен sha1. Он может проверять имена ссылок, так как они передаются (вместе с подсказками их ветвей или другими значениями SHA-1) спереди, поэтому git clone -b nonexistentbranch ssh://... быстро заканчивается и не создает копию:
fatal: Remote branch nonexistentbranch not found in upstream origin
fatal: The remote end hung up unexpectedly
Если -b разрешил идентификатор, вы получили бы весь клон, тогда он должен был бы сказать вам: "О, черт возьми, извините, не могу проверить этот идентификатор, я оставлю вас на хозяине" или что-то еще. (Что более или менее то, что происходит сейчас с перегруженным подмодулем.)
1 Пока git upload-archive теперь применяет это правило "конфиденциальности", это не всегда так (оно было введено в версии 1.7.8.1); и многие (большинство?) git -web-серверов, в том числе и распределенные с самим Git, позволяют просматривать по произвольному идентификатору. Вероятно, поэтому allowUnreachable был добавлен в upload-archive через несколько лет после добавления кода "только по имени ref" (но обратите внимание, что релизы Git после 1.7.8 и до 2.0.0 не имеют возможности ослабить правила). Следовательно, хотя идея "безопасности" действительно, существовал период (до 1.7.8.1), когда он не был применен.
2 Существует множество способов "утечки" якобы частных данных из репозитория Git. Новый файл, Documentation/transfer-data-leaks, должен появиться в Git 2.11.1, а Git 2.11.0 добавил некоторые внутренние (см. commit 722ff7f87 среди других), чтобы немедленно удалить объекты, нажатые, но не принятые. Такие объекты в конечном итоге собираются с мусором, но это оставляет их выставленными в течение продолжительности.
3 Фактически, по умолчанию git clone делает локальную проверку ветки, которая, по его мнению, идет с удаленной ссылкой HEAD. Обычно это master в любом случае.