В опции git clone --depth указано
--depth <depth>
Create a shallow clone with a history truncated to the specified number of revisions.
A shallow repository has a number of limitations
(you cannot clone or fetch from it, nor push from nor into it),
but is adequate if you are only interested in the recent history of a large project with a long history,
and would want to send in fixes as patches.
Почему мелкие клоны имеют это ограничение? Почему это патч только рабочий процесс?
Для некоторых рабочих процессов проекта мне нужно передать только последнюю фиксацию из одной ветки в кодер, а затем предоставить им возможность push их (ускоренную перемотку) событий на главный сервер. Это частично для безопасности, защиты IP и размера репо, а частично для уменьшения путаницы, которую большое репо принесет наивному кодеру. Есть ли git рабочий процесс, который позволяет это?
Обновление: на основании ответа Карла Билефельда ответ git checkout --orphan должен быть правильным ответом. Но по-прежнему нужно "клонировать" эту ветку только новому пользователю и иметь возможность эффективно ее продвигать.
На странице пользователя указано:
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>] --orphanСоздайте новую сиротскую ветвь с именем
<new_branch>, начиная с<start_point>и переключитесь на него. Первая фиксация сделана на этом новом у ветки не будет родителей, и это станет корнем новой истории полностью отключен от всех других ветвей и совершает.Индекс и рабочее дерево настроены так, как если бы вы ранее запустите
git checkout <start_point>. Это позволяет вам начать новый история, которая записывает набор путей, похожих на<start_point>на легко запуститьgit commit -a, чтобы сделать фиксацию root.Это может быть полезно, когда вы хотите опубликовать дерево из фиксации не подвергая его полной истории. Вы можете сделать это, чтобы опубликовать ветку с открытым исходным кодом проекта, текущее дерево которого "чистый", но чья полная история содержит проприетарные или иные обремененные биты кода.
Если вы хотите запустить отключенную историю, которая записывает набор путей, которые полностью отличаются от тех, что относятся к
<start_point>, то вы должны очистить индекс и рабочее дерево сразу после создания сиротская ветвь, запустивgit rm -rf .с верхнего уровня рабочее дерево. После этого вы будете готовы подготовить свои новые файлы, заполняя рабочее дерево, копируя их из другого места, извлечение tarball и т.д.
Интересна ссылка VonC на комментарии Junio. Я думаю, что руководство должно обеспечить руководство в этом случае и разрешить правильную команду [например. clone <branch> --options], чтобы извлечь только соответствующую часть репо. Очевидно, что вероятность успеха push возрастает за счет наличия нескольких связанных коммитов и SHA1 в нижней части истории, которые блокируют соответствие репо.
Обновление git 1.9.0: примечания к выпуску 14 Фев '14.
"Извлечение из мелко-клонированного хранилища было запрещено, прежде всего потому, что вовлеченные кодеки не были тщательно проверены и мы не потрудились поддерживать такое использование. Эта попытка освобождения разрешить передачу объекта из мелко-клонированного репозитория в более контролируемый способ (т.е. приемник становится мелким хранилищем с усеченной историей).
Это хорошая новость для мелких клониров. Далее - Узкие клоны, возможно.