Git клон не позволяет клонировать репозиторий рабочей копии (не пустой) - PullRequest
0 голосов
/ 24 апреля 2020

Если вы сделаете клон рабочей копии git (хранилище с рабочим деревом), измените некоторые файлы, зафиксируете и попытаетесь выполнить команду pu sh, и вы получите сообщение:

remote: error: refusing to update checked out branch: refs/heads/master
...
! [remote rejected] master -> master (branch is currently checked out)

Это понятное и желаемое мне поведение.

Я бы хотел предотвратить случайное клонирование рабочей копии репозитория.

Как предотвратить клонирование git клонирования рабочих копий вместо удаленных открытых репозиториев и сообщить об ошибке в случае попытки клонирования рабочей копии?

Есть ли переключатель командной строки, который вызывает git клонирование ненулевого состояния выхода в случае попытки клонировать рабочую копию вместо чистого удаленного репозитория?

Если нет, то как проверить местоположение репозитория (url или путь к dir), если оно содержит пустой репозиторий, поэтому я могу проверить это в bash перед клонированием.

Обратите внимание, что рабочая копия репозитория не обязательно означает, что она локальная, так как она также может использоваться удаленно.

В моем случае git клон должен быть разрешен только для работы с git голыми репозиториями и сообщать об ошибке, если используется для клонирования рабочей копии.

Ответы [ 2 ]

2 голосов
/ 25 апреля 2020

Нет способа помешать вам клонировать репозиторий с рабочим деревом. Когда Git фиксирует содержимое в репозитории, они доступны путем доступа к каталогу .git или его эквиваленту без какой-либо проверки или манипулирования рабочим деревом.

Это на самом деле чрезвычайно важно для безопасности, поскольку один из единственное безопасное, что вы можете сделать с ненадежным репозиторием, - это клонировать или извлечь его. Если вам помешают это сделать, вы не сможете безопасно получить данные из ненадежных репозиториев.

Вы можете проверить, есть ли у локального репозитория рабочее дерево, запустив git rev-parse --is-bare-repository в репозитории в вопрос (или используя -C). Он напечатает true, если он пуст (то есть, не имеет рабочего дерева), и false, если это не так. Вы не можете проверить это в репозитории, который не доступен через локальную файловую систему (например, HTTPS или S SH remote), потому что это потребует от вас возможности проверить файловую систему удаленной системы, и это будет проблемой безопасности, если это могут делать удаленные пользователи.

Я рекомендую не слишком беспокоиться об этом сценарии, а не пытаться бороться с этим Git. Такое поведение создает мало практических проблем и, как правило, не должно вызывать беспокойства.

1 голос
/ 25 апреля 2020

Чтобы увеличить ответ bk2204 , вы должны думать о рабочем дереве как , не являющемся частью репозитория ... потому что в довольно сильном смысле это не является частью хранилища. Поскольку рабочее дерево не является частью репозитория, оно никогда не копируется git clone. Это означает, что здесь нет проблем.

(индекс Git и файлы, скопированные в индекс, являются, по крайней мере, частью хранилища, но сам индекс не копируется. Blob объекты - содержимое файла - которые были недавно сохранены в репозитории Git через git add, но которые еще не были зафиксированы, могут потенциально быть скопированы, хотя в общем случае объекты, на которые нет ссылок, не должны копироваться во время клонирование. Я почти уверен, что я нашел экземпляры объектов без ссылок в клоне fre sh хотя бы один раз, обратно в Git 1.5.5 / Git 1.6-i sh дней. Но рабочее дерево Файлы , которые никогда не были git add -ed, вообще не представлены в базах данных репозитория , и они копируются во время клонирования.)

...