Почему нет опции фиксации Git Clone?
В свете недавнего вопроса о SO, мне интересно, почему нет выбора в git clone такой, что HEAD указатель вновь созданной ветви будет указывать на указанный коммит? В приведенном выше вопросе OP пытается предоставить инструкции по конкретному коммиту, который должны клонировать его пользователи.
Обратите внимание, что этот вопрос не о том, как клонировать в конкретную версию с помощью reset; а почему нет?
4 ответа
Пока что два ответа (в то время, когда я писал это, теперь их было больше) верны в том, что они говорят, но на самом деле не отвечают на вопрос "почему". Конечно, на вопрос "почему" действительно сложно ответить, кроме как авторами различных частей Git (и даже тогда, что, если два частых участника Git дали два разных ответа?).
Тем не менее, учитывая "философию" Git, как правило, различные протоколы передачи работают, называя ссылку. Если они предоставляют SHA-1, это SHA-1 этой ссылки. Для тех, кто еще не имеет прямого (например, командной строки) доступа к хранилищу, ни одна из встроенных команд не позволяет ссылаться на коммиты по ID. Самая близкая вещь, которую я могу найти к причине этого - и это на самом деле хорошая причина 2 - это немного в git upload-archive документация:
БЕЗОПАСНОСТЬ
Чтобы защитить конфиденциальность объектов, которые были удалены из истории, но, возможно, еще не были удалены, git-upload-archive избегает обслуживания архивов для коммитов и деревьев, которые недоступны из ссылок репозитория. Однако, поскольку вычисление достижимости объекта требует больших вычислительных ресурсов, git-upload-archive реализует более строгий, но более простой для проверки набор правил...
Тем не менее, он продолжает говорить:
Если опция конфигурации
uploadArchive.allowUnreachableЭто правда, эти правила игнорируются, и клиенты могут использовать произвольные выражения sha1. Это полезно, если вы не заботитесь о конфиденциальности недоступных объектов или если ваша база данных объектов уже общедоступна для доступа через non-smart-http.
что особенно интересно, так как 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-веб-серверы, включая тот, который распространяется вместе с Git, позволяют просматривать по произвольному идентификатору. Наверное, поэтому allowUnreachable был добавлен в upload-archive через несколько лет после добавления кода "только по имени" (но учтите, что выпуски 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 в любом случае, хотя.
Клонирование репо - это другая операция, чем оформление заказа. Вы не "клонируете конкретный коммит". Для удобства вы можете клонировать и затем извлекать конкретную ранее существующую ветку одновременно, так как это то, чего хочет большинство людей. Если это не отвечает вашим потребностям (нет ветки для конкретного SHA, который вы хотите), просто используйте или псевдоним какой-либо формы
git clone -n <some repo> && cd <some repo> && git checkout SHA
Если на ваш конкретный коммит ссылается ветка, вы можете сделать:
git clone -b yourBranch /url/of/the/repo
Клонированное хранилище будет непосредственно при коммите, на который ссылается эта ветка.
Как говорят другие ответы, это обычно не большая проблема, но они не говорят, почему вы не можете клонировать конкретный коммит. Ответ - безопасность.
Если вы случайно отправите конфиденциальную информацию, а затем принудительно отправите фиксированную историю, фиксации с конфиденциальной информацией все еще будут храниться на сервере, пока сборщик мусора сервера Git не обнаружит, что он больше не нужен. Если хеш известен (например, он может быть доступен в журналах), злоумышленник может запросить конкретную фиксацию, которую не нужно было выдвигать, даже если вы смогли проверить, что при принудительном нажатии фиксированной истории никто не будет уже получил эти коммиты.
Удостоверившись, что вы можете клонировать только из ссылок, убедитесь, что клиентам будут отправлены только "достижимые" коммиты.