Проблема и мотивация
У нас есть большой git репозиторий на нашем центральном сервере. В нем много истории, которую мы хотим сохранить, поэтому перебирать или раздавливать что-либо там на самом деле не вариант. Однако при клонировании репозитория на наши серверы разработки на самом деле актуальна только недавняя история. Для нас «недавний» может быть определен как заданный тег, и любой коммит ранее в истории может быть опущен. Цель здесь - сэкономить пропускную способность, время и дисковое пространство.
Идеи для подхода
Текущая идея состоит в том, чтобы клонировать только этот тег, используя git clone --branch my-root-tag --depth 1, рассматривая его как искусственный root коммит в этом локальном хранилище. После этого добавляем ветки, которые мы хотели бы получить вручную, используя git remote set-branches --add origin some-branch. Все эти ветви должны включать my-root-tag где-то в своей истории. Тем не менее, каждый выбор теперь снова перенесет всю историю. Есть ли способ ограничить выборки остановкой на my-root-tag? Похоже, что для этого подхода потребуется что-то вроде запроса в git мелком клоне, так как спецификатор c commit , в идеале заключенный в псевдоним git для «динамического» вычисления значения параметра --depth .
Может кто-нибудь придумать, как заставить это работать или даже применить совершенно иной подход?
Результаты
edit : Подводя итог, кажется, что git fetch действительно передает только коммиты в новый привитой репозиторий root (по крайней мере в Git v 2.25.1). Только исходный clone должен быть правильно параметризован, в то время как последующие операции с хранилищем могут выполняться с использованием обычных (непараметризованных) команд git. Никакие опции shallow-include или shallow-exclude сейчас на самом деле не нужны. Это хорошая новость, так как она делает эту конфигурацию намного дешевле agile, чем первоначально опасалось.