Как эффективно использовать git fetch из мелкого клона

--depth - это вариант git fetch. Я вижу, что документ на самом деле не подчеркивает, что git clone выполняет выборку.

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

--depth=1 выборка просто получает подсказки веток, а не предыдущую историю. Дальнейшие выборки этих историй будут извлекать все новое с помощью вышеупомянутой процедуры, но если ранее извлеченные коммиты не вошли в недавно извлеченную историю, выборка извлечет все это - если вы не ограничите выборку с помощью --depth.

Ваш клиент выполнил выборку глубины = 1 из одного репо и переключил URL-адреса на другое репо. По крайней мере, один длинный путь предков в ссылках этого нового репо, по-видимому, не имеет никаких коммитов ни с чем, что в настоящее время находится в вашем репо. Возможно, это стоит изучить, но в любом случае, если нет какой-либо особой причины, ваши клиенты могут просто выполнять каждое извлечение --depth=1.

Только что сделал g clone github.com:torvalds/linux, и это заняло так много времени, что я просто пропустил CTRL+C.

Потом сделал g clone github.com:torvalds/linux --depth 1, и он клонировал довольно быстро. И у меня есть только одна фиксация в git log.

Так что clone --depth 1 должно работать. Если вам нужно обновить существующий репозиторий, вы должны использовать git fetch origin remoteBranch:localBranch --depth 1. Он тоже работает, он получает только одну фиксацию.

Подводя итоги:

Исходный клон:

git clone git_url --depth 1

Обновление кода

git fetch origin remoteBranch:localBranch --depth 1

Обратите внимание, что Git 1.9 / 2.0 (первый квартал 2014 г.) может быть более эффективным при извлечении неглубокого клона.
См. совершить 82fba2b, от Нгуен Тай Нгук Дуй (pclouds):

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

Все подробности приведены в shallow.c: 8 шагов для выбора новых коммитов для .git/shallow.

Вы можете увидеть последствия в таких коммитах, как 0d7d285, f2c681c, и c29a7b8, которые поддерживают клонирование, send-pack / receive-pack с / из мелких клонов.
https://github.com/git/git/commit/16094885ca94f72abc28a915f9aa4021e203a16d.
Вы можете даже клонировать из неглубокого репо.

Обновление 2015 г .: git 2.5+ (второй квартал 2015 г.) позволит даже выборку за одну фиксацию! См. Извлечение определенной фиксации из удаленного репозитория git.

Обновление 2016 (октябрь): git 2.11+ (4 квартал 2016 г.) позволяет получать:

• с даты --shallow-since=<date>
• до фиксации --shallow-exclude=<commit>
• с большей глубиной: --deepen=N

Если вы можете выбрать конкретную ветку, это может быть еще быстрее. Вот пример использования основной ветки Spark и последнего тега:

Первоначальный клон

git clone [email protected]:apache/spark.git --branch master --single-branch --depth 1

Обновление до определенного тега

git fetch --depth 1 origin tags/v1.6.0

Таким образом становится очень быстро переключать теги / ветвь.

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

git clone --depth 1 --reference /path/to/local/clone [email protected]/group/repo.git 

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

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