Ответ на реальный вопрос
Локальные клоны с git обычно не занимают тонны дополнительного места, потому что git будет использовать жесткие ссылки для обмена объектными файлами.Это трудно заметить - если вы запускаете du
в каждом репо, вы получите полный размер, но если вы запустите его на двух вместе, вы должны увидеть экономию.Я предполагаю, что вы по какой-то причине решили, что этого недостаточно.Возможно, вы находитесь в файловой системе, которая не поддерживает жесткие ссылки, или клоны находятся на отдельных дисках или что-то в этом роде ... кто знает.
В любом случае, если вы хотите создать легкий клон,экономя место, почему бы не сэкономить все место?В каталоге ссылок git есть прекрасный скрипт с именем git-new-workdir
(ссылка на текущую версию в git.git).Он создает новый рабочий каталог из репозитория, с каталогом .git, по существу, общим для всех с помощью символических ссылок - практически единственное, что не является HEAD
.Оставьте скрипт где-нибудь на вашем пути, и вы сможете запустить его как обычную команду git:
git new-workdir <original-repo> <new-workdir-path>
Вуаля!Теперь у вас есть два рабочих дерева с общим каталогом .git, поэтому единственное дополнительное пространство, которое вы занимаете, это файлы рабочего дерева.Нет пути, если вы хотите работать!
Единственное, к чему вы должны быть осторожны, это проверять одну и ту же ветку в обоих репозиториях.Если вы затем фиксируете эту ветку в одном репо, другой станет не синхронизированным - рабочее дерево и индекс не будут соответствовать коммиту, в котором сейчас находится ветка.В противном случае вы можете счастливо работать в обоих репозиториях!
Оригинальный ответ
Позвольте мне сначала заявить, что, по сути, у вас нет шансов сделать это.Я серьезно.Это едва ли сэкономит вам место на диске, в то время как репозитории с жестко связанными объектами (по умолчанию! Вам даже не нужно ничего делать, чтобы получить это!) Сэкономят вам тонну.
InПрактически в каждом случае филиалы делят большую часть своей истории.Потенциал для экономии места есть только в той небольшой части, в которой они разошлись.Посмотрите на git log branchA..branchB
.Это те коммиты, объекты которых вы будете избегать копировать.Там есть какие-то огромные бинарные файлы?Любые 1000-строчные различия?Нет?Тогда не беспокойтесь об этом.Это вам не поможет.
Все еще читаете?Хорошо, ну, я не думаю, что git-clone
позволяет вам связываться с refspec (за исключением --mirror
, но это, очевидно, не то, что мы ищем здесь).Если это действительно важно сделать, вы можете управлять этим, создав пустой репозиторий и вытянув его, а затем тщательно выполнив остальную часть настройки, которую сделал бы клон:
mkdir foo && cd foo && git init
git remote add origin <url>
# set up a refspec to get the branch(es) you want
git config remote.origin.fetch "+refs/heads/foo:refs/remotes/origin/foo ..."
git fetch origin
У вас все еще есть некоторыеКонфигурация отсутствует - в частности, у вас есть локальная главная ветка, которая ничего не отслеживает.
Это довольно странная установка, которая не захватывает все ветви из источника, но я полагаю, это должно работать.Конечно, как я уже сказал в своем комментарии, вы не избавите себя от многих проблем.Извлечение других удаленных веток не означает, что вам нужно создавать соответствующие локальные ветки, и если эти исключенные ветки не будут сильно отличаться от тех, которые вы захватили (то есть содержат много уникального контента), вы не сэкономите много пропускной способности или дискового пространства.