Почему я не могу оттолкнуться от мелкого клона? - PullRequest
Новая
       23

Почему я не могу оттолкнуться от мелкого клона?

42 голосов
/ 01 августа 2011

Параметр команды 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, чтобы сделать корневой коммит.

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

Если вы хотите начать отключенную историю, которая записывает набор пути, которые полностью отличаются от одного из <start_point>, то Вы должны очистить индекс и рабочее дерево сразу после создания сиротская ветвь, запустив git rm -rf . с верхнего уровня рабочее дерево. После этого вы будете готовы подготовить новые файлы, перезаполнение рабочего дерева, копируя их из другого места, извлечение тарбола и т. д.

Интересная ссылка VonC на комментарии Junio. Я думаю, что руководство должно обеспечить руководство в этом случае и позволить правильную команду [например, clone <branch> --options], чтобы извлечь только соответствующую часть репо. Очевидно, что вероятность успеха push увеличивается благодаря наличию нескольких связанных коммитов и SHA1 в нижней части истории, которые блокируют сопоставление репо.

Обновление Git 1.9.0: заметки о выпуске 14 февраля '14.

«Извлечение из мелко клонированного хранилища раньше было запрещено, в первую очередь потому, что соответствующие пути и мы не удосужились поддержать такое использование. Этот релиз пытается чтобы разрешить перенос объекта из мелко клонированного хранилища в более контролируемый способ (т.е. получатель становится мелким хранилищем с усеченной историей). "

Это хорошая новость для мелких клонеров. Далее - возможно узкое клонирование.

Ответы [ 2 ]

22 голосов
/ 01 августа 2011

Как говорит Джунио С. Хамано (главный сопровождающий Git) :

Не является ли правило более или менее похожим на:

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

Обновление 2014 года: см. " Является ли git clone --depth 1 (мелкий клон) более полезным, чем он показывает? ": это ограничение будет снято с помощью Git1.9!

Обновление 2015: с Git 2.5+ вы даже сможете получить один коммит .Смотрите « Извлечение определенного коммита из удаленного репозитория git »

Оригинальный ответ (август 2011):

Собственно, подумайте об этом, это намного сильнее, чем «не может вычислить общее».

История может выглядеть так: 

          R---R---R
         /
  --R---R---X---X---S---S---S

, где S - коммиты, которые вы делаетеесть в вашем мелком репозитории, и R - это коммиты, которые существуют в репозитории, который получает ваш толчок.
Поскольку ваша история мелкая, ни один из репозиториев не имеет 'X', которые являются коммитами, которые должны существовать в порядкевести полную историю репозитория получателя;для начала получатель не мелкий, и мы не хотим делать его мелким.

Если вы клонировали некоторое время назад, работали без связи с другой стороной, в то время как другая сторона развивалась, AND если бы прогресс другой стороны включал перемотку и перестройку истории, вы бы увидели похожую топологию.
Самый левый 'S' на рисунке выше, возможно, был верхушкой ветви, когда вы клонировали мелкос глубиной 1, и с тех пор удаленный конец, возможно, отбросил три верхних коммита и перестроил свою историю, что приводит к крайнему правому «R».
В таком случае нажатие на HEAD на пульте не удастся.

Так что может в некоторых случаях работать, но не поддерживается:

Если мне нужно что-то сказать по этому поводу ...

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

  • Не все умны;некоторые сами пробуют это, видят, что операция , кажется, работает для их ограниченного числа испытаний, и решили, что она будет работать большую часть времени.
    И они поздравляют свой собственный интеллект с тем, что он сказал "большинствовремени ", а не" всегда ".
    И они расстраиваются, когда видят, что это не работает, даже если их предупреждают.

Для получения дополнительной информации о процессе обновления мелкого клона см. « Как обновить мерзкий клон git? ».

9 голосов
/ 01 августа 2011

Есть ли рабочий процесс git, который позволяет это?

Да, это исправления в виде исправлений. git format-patch специально разработан для этого. Это называется рабочий процесс «привратник», если вы хотите, чтобы Google для более подробной информации. Трудно поверить в то, что организация обеспокоена «безопасностью и защитой ИС», поскольку ваша организация еще не использует нечто подобное, когда один человек или небольшая группа отвечает за проверку «ненадежных» изменений, прежде чем они внесут их в реальную сборку.

Исходя из вашего комментария, теперь я лучше понимаю ваши требования. Я бы порекомендовал создать ветку orphan (см. git checkout --orphan ), с какой бы точки вы ни захотели запустить своих разработчиков. Клонируйте только эту ветвь в другое хранилище, доступное для этих разработчиков, и пусть они обычно клонируют, толкают и извлекают из этого репо.

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

Это немного сложнее, чем обычно, но это цена, заплаченная за дополнительную изоляцию.

...