Предварительная загрузка репозитория git?
Если у меня уже есть те же файлы локально, вместо того, чтобы вытащить большой каталог файлов из удаленного репозитория, есть ли способ "предварительно загрузить" мой локальный репозиторий с файлами? У меня уже есть те же файлы локально, что и на удаленном, их просто нет в локальном репо.
Вот моя ситуация:
У меня есть удаленный веб-сайт, который имеет большой (много концертов) каталог ресурсов (изображения, PDF, swfs, flvs). Я установил репозиторий git для этого удаленного сайта и клонировал его локально, используя файл.gitignore, чтобы исключить включение большого каталога ресурсов в репозиторий.
Я бы хотел сделать каталог больших ресурсов частью удаленного репо, но это резко увеличит размер репо, и когда я сделаю следующее локальное извлечение, меня ждет очень долгое ожидание / загрузка. Так что я в основном надеюсь, что есть способ сказать git: "Я попрошу вас вытащить тот репо, который внезапно стал намного больше, но у меня уже есть большая часть того, что делает его таким большим"? Или это может пойти другим путем, когда я сначала добавляю файлы в локальный репозиторий, а затем каким-то образом репозитории решают, что у них одни и те же файлы и передача не требуется?
Это также пригодится, когда новые разработчики будут привлечены к большому проекту, и большая его часть может быть предоставлена на DVD, вместо того, чтобы им приходилось клонировать / загружать огромное репо.
3 ответа
Я предлагаю вам быть очень осторожным при выработке привычки добавлять гигабайты двоичных файлов в ваш git, не обращая внимания на такие опции, как git-annex.
Сейчас. Для того, чтобы Git мог использовать их, недостаточно иметь сами файлы. Вы могли бы использовать git hash-object вручную добавить большие двоичные файлы в базу данных объектов Git по обе стороны от большого сетевого разрыва и создать коммит, содержащий точно такие же файлы на другой стороне, но при вставке / извлечении такого коммита Git не достаточно умен, чтобы понять, что эти объекты уже существуют на другой стороне; поскольку фиксация, которая должна быть передана, не существует, большие капли будут включены в результирующий пакетный файл, который передается по проводам. Чтобы избежать этого, вам нужно будет вручную скопировать все объекты коммитов и деревьев, но пропустить большие капли. Выполнимо, но, вероятно, больше проблем, чем оно того стоит.
Более реалистичный подход состоит в том, чтобы один раз принять удар по сетевой передаче и быть внимательным к будущим передачам. Вы можете иметь местное зеркало, из которого люди могут клонировать. Если это также не достаточно быстро, это означает, что ваш мерзавец слишком большой.
Вы также можете клонировать мерзавца с git clone --reference <ref> <url>, где <ref> это локальный каталог, содержащий git, который вы клонируете. Это позволит повторно использовать все объекты из эталонного git, что сделает клон чрезвычайно быстрым. Однако, как отмечено в git clone manpage, новый клон будет напрямую ссылаться на объекты в старом клоне, поэтому, если старый клон будет удален, у вас возникнут проблемы. Чтобы на самом деле скопировать объекты, которые вы можете запустить git repack -a после клонирования.
git clone --reference /some/old/clone http://example.com/some/git dirname
cd dirname
git repack -a
rm .git/objects/info/alternates
Последняя команда удаляет ссылку на ссылочный git, поэтому Git не будет пытаться искать там объекты в будущем.
Чтобы распространять Git-репозиторий, например, на DVD или аналогичных механизмах хранения, изучите git bundle, Смотрите, например, Как сделать Git Bundle полным репо.
Я только поместил исходный код git, все части картинок, pdfs, изображения. .. Я хотел бы создать отдельный сервер хранения, и в моем приложении я ссылку на хранилище.
Сегодня (4 квартал 2017 года / 1 квартал 2018 года, через 4 года после вопроса ОП), единственный связанный с Git способ клонирования огромного репозитория Git был бы через (февраль 2017 года) GVFS (виртуальная файловая система Git).
Как написано в твиттере для репо на 270 Гб:
"База кода Windows содержит более 3,5 миллионов файлов. С GVFS (Git Virtual File System) клонирование теперь занимает несколько минут вместо 12+ часов ".
Увидеть github.com/Microsoft/GVFS,
GVFS основан на Git- форке: github.com/Microsoft/git,
И на основе протокола, спецификации которого описаны здесь.
Это пока не поддерживается EGit, или даже обычным Git, но интеграция такого механизма началась с Git 2.16 (Q1 2018) и реализацией узкого / частичного клона, где была использована машина для перемещения объектов. научил его "фильтровать" некоторые объекты из перечисления.
Это результат обсуждения частичного клонирования, задокументированного здесь (ноябрь 2017 г.), хотя эта проблема была освещена еще в мае 2013 г.:
При работе с большими репозиториями необходимость извлечения всех объектов в области истории, которая интересует пользователя, расточительна.
Это особенно верно в двух случаях:
использование разреженной проверки: объекты вне каталога, на который смотрит пользователь, вряд ли когда-либо понадобятся. Позже пользователь должен иметь возможность извлекать объекты из этого каталога, если они оказываются необходимыми (например, если расширяется разрозненная проверка). Это особенно полезно в сочетании с виртуальной файловой системой, которая определяет шаблон разреженного извлечения для использования автоматически ( https://blogs.msdn.microsoft.com/devops/2017/02/03/announcing-gvfs-git-virtual-file-system/).
репозиторий содержит большие двоичные файлы: исторические версии больших файлов не нужны для создания последней версии кода.
Использование мелкого клона теряет способность использоватьgit log"понять историю проекта в процессе разработки.
Для использования Git LFS необходимо заранее предвидеть эту проблему и заранее решить, какие файлы выгружать в LFS.
Наличие собственной поддержки в Git для исключения больших сгустков позволяет избежать этой дилеммы.Microsoft и Google внутренне используют исправления для поддержки частичного клонирования и публикуют свои исправления. Эта проблема отслеживает включение функциональности в Git upstream.
В следствии:
См. Коммит f4371a8, коммит 4875c97 (05 декабря 2017 г.) и коммит 9535ce7, коммит caf3827, коммит 25ec7bc, коммит c3a9ad3, коммит 314f354, коммит 578d81d (21 ноября 2017 г.) от Jeff Hostetler ( jeffhostetler )
Смотрите коммит 1dde5fa (05 декабря 2017) от Christian Couder ( chriscool )
(Объединено Юнио С Хамано - gitster - в коммите 61061ab, 27 декабря 2017 г.)
rev-list/pack-objects: добавлена поддержка фильтрации списка объектовНаучите rev-list использовать фильтрацию, предоставляемую
traverse_commit_list_filtered()интерфейс для исключения ненужных объектов из результата.В будущем мы введем механизм "частичного клонирования", в котором объект в репо, полученный с пульта, может ссылаться на отсутствующий объект, который может быть динамически извлечен из этого пульта, когда это необходимо.
Этот механизм "частичного клонирования" будет иметь способ, иногда медленный, определять, является ли недостающее звено одним из звеньев, которые, как ожидается, будут созданы этим механизмом.Этот патч вводит обработку отсутствующих объектов, чтобы помочь отладке и разработке механизма "частичного клонирования", и, как только механизм будет реализован, для опытного пользователя выполнять операции, которые осведомлены об отсутствующем объекте, не неся затрат на проверку, если отсутствует ссылка ожидается.