Почему нет конкретной опции фиксации git Clone?

два ответа до сих пор (в то время, когда я писал это, теперь их больше) верны в том, что они говорят, но на самом деле не отвечают на вопрос "почему". Конечно, на вопрос "почему" действительно трудно ответить, кроме авторов различных бит Git (и даже тогда, что, если два частых участника Git дали два разных ответа?).

тем не менее, учитывая "философию" Git, как это было, в целом, различные протоколы передачи работают, называя ссылка. Если они предоставляют SHA-1, это SHA-1 этой ссылкой. Для тех, кто еще не имеет прямого (например, командной строки) доступа к репозиторию, none¹ встроенных команд позволяют ссылаться на коммиты по ID. Самое близкое, что я могу найти к причина для этого-и это на самом деле хорошая причина²-это бит в на git upload-archive документация:

безопасность

для защиты конфиденциальности объектов, которые были удалены из история, но, возможно, еще не была обрезана, git-upload-archive избегает обслуживание архивов для коммитов и деревьев, недоступных из refs репозитория. Однако, поскольку вычисление достижимости объекта вычислительно дорого, git-upload-archive реализует более строгий, но проще проверить набор правил ...

если параметр config uploadArchive.allowUnreachable правда, эти правила игнорируются, и клиенты могут использовать произвольные выражения sha1. Этот полезно, если вы не заботитесь о конфиденциальности недостижимых объектов, или если ваша база данных объектов уже доступна для доступа через non-smart-http.

что особенно интересно, так как git clone получает все доступные объекты в первую очередь, после чего ваш локальный клон может тривиально проверить фиксацию по идентификатору SHA-1 (и создать имя локальной ветви, указывающее на этот идентификатор, если это необходимо, или просто оставьте свой клон в режиме "отсоединенная голова").

учитывая эти два перекрестных течения, я думаю, что реальный ответ на "почему", на данный момент, "никто не заботится о том, чтобы добавить его". :- ) Аргумент конфиденциальности действителен, но нет никаких причин, что git clone не удалось проверить фиксацию по ID после клонирования, так же, как это можно сказать, чтобы проверить некоторую ветку, отличную от master³ С git clone -b .... Единственный недостаток разрешения -b sha1 это то, что Git не может проверить спереди (до начала процесса клонирования), является ли sha1 будет получено. Это can проверьте ссылочные имена, так как они передаются (вместе с их наконечниками ветвей или другими значениями SHA-1) спереди, поэтому git clone -b nonexistentbranch ssh://... быстро завершается и не создает копию:

fatal: Remote branch nonexistentbranch not found in upstream origin
fatal: The remote end hung up unexpectedly

если -b разрешен ID, вы получите весь клон, тогда он должен будет сказать вам: "о, боже, извините, не могу проверить этот ID, я буду вместо этого оставляю тебя на хозяина " или что-то еще. (Что более или менее происходит сейчас с лопнувшим подмодулем.)

¹пока git upload-archive теперь применяет это правило "конфиденциальности", это было не всегда так (оно было введено в версии 1.7.8.1); и многие (большинство?) git-веб-серверы, в том числе распределенные с самим Git, позволяют просматривать по произвольному идентификатору. Это, вероятно, почему allowUnreachable добавлено upload-archive через несколько лет после "только ref имя " код был добавлен (но обратите внимание, что выпуски Git после 1.7.8 и до 2.0.0 не имеют возможности ослабить правила). Следовательно, хотя идея "безопасности" является действительной, был период (до 1.7.8.1), когда она не была применена.

²существует множество способов "утечки" якобы частных данных из репозитория Git. Новый файл,документация / передача-утечка данных, собирается появиться в Git 2.11.1, в то время как Git 2.11.0 добавил некоторые внутренние функции (см. совершить 722ff7f87 среди других), чтобы немедленно отбросить объекты, толкнутые, но не принятые. Такие объекты в конечном итоге собирают мусор, но это оставляет их открытыми на время.

³на самом деле, по умолчанию git clone локальная отъезда из филиала он думает, что идет с пульта HEAD ссылка. Обычно это master в любом случае, хотя.