Как обновить неглубокий клонированный субмодуль без увеличения размера основного репо

Question

Я хочу преобразовать в git существующую кодовую базу, в которой есть большие файлы двоичных библиотек. Файлы библиотеки являются внешними (от поставщика) зависимостями. Эти двоичные файлы необходимы только для связи конечного приложения. Размер этих бинарных файлов огромен (2, 2 гигабайта), поэтому, чтобы уменьшить размер основного репо (и не нужно чрезмерно увеличивать размер основного репо), я бы хотел разместить бинарные файлы в git-репо и использовать субмодуль для Ссылка только на последнюю версию двоичных файлов библиотеки.

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

Структура репо у меня похожа на это:

main_project
    sub_binary
    other project files
    ...

вот команды, которые позволили мне иметь мелкий подмодуль:

cd main_project
git submodule add --depth 1 file://remote_binary_repo_path sub_binary

Это работает, и sub_binary прикреплен к правильной ревизии.

Как мне обновить мелкий субмодуль sub_binary (и запишите это в main_repo) до последней версии (и только до последней версии), если удаленное хранилище библиотеки будет обновлено?

Заметки:

• если я делаю git log в sub_binary в начальной настройке подмодуля, я получаю ожидаемую историю одного коммита.
• когда я пытаюсь сделать git pull --depth 1 в sub_binary, Я получаю ошибку слияния: автоматическое слияние не удалось; исправить конфликты, а затем зафиксировать результат.
• Я использую git 1.8.4
• Я прочитал ответ VonC на Git Shallow Submodules, но там не упоминается, как обновить такой подмодуль.

Редактировать:

Я смог обновить субмодуль после большого изучения мерзавцев ( см. Мой собственный ответ). Но есть еще проблема, что основной репо растет по мере поступления новых версий.

Для теста у меня есть бинарный файл размером 2 мегабайта, и я мелко клонируюсь, чтобы создать субмодуль. du -h в начальном клоне после git submodule update --init --depth 1:

 40K    ./.git/hooks
4.0K    ./.git/info
4.0K    ./.git/logs/refs/heads
4.0K    ./.git/logs/refs/remotes/origin
4.0K    ./.git/logs/refs/remotes
8.0K    ./.git/logs/refs
 12K    ./.git/logs
 40K    ./.git/modules/sub_binary/hooks
4.0K    ./.git/modules/sub_binary/info
4.0K    ./.git/modules/sub_binary/logs/refs/heads
4.0K    ./.git/modules/sub_binary/logs/refs/remotes/origin
4.0K    ./.git/modules/sub_binary/logs/refs/remotes
8.0K    ./.git/modules/sub_binary/logs/refs
 12K    ./.git/modules/sub_binary/logs
  0B    ./.git/modules/sub_binary/objects/info
2.0M    ./.git/modules/sub_binary/objects/pack
2.0M    ./.git/modules/sub_binary/objects
4.0K    ./.git/modules/sub_binary/refs/heads
4.0K    ./.git/modules/sub_binary/refs/remotes/origin
4.0K    ./.git/modules/sub_binary/refs/remotes
  0B    ./.git/modules/sub_binary/refs/tags
8.0K    ./.git/modules/sub_binary/refs
2.1M    ./.git/modules/sub_binary
2.1M    ./.git/modules
4.0K    ./.git/objects/70
4.0K    ./.git/objects/de
4.0K    ./.git/objects/info
8.0K    ./.git/objects/pack
 20K    ./.git/objects
4.0K    ./.git/refs/heads
4.0K    ./.git/refs/remotes/origin
4.0K    ./.git/refs/remotes
  0B    ./.git/refs/tags
8.0K    ./.git/refs
2.2M    ./.git
2.0M    ./sub_binary
4.2M    .

du -h после двух или трех циклов обновления:

 40K    ./.git/hooks
8.0K    ./.git/info
4.0K    ./.git/logs/refs/heads
4.0K    ./.git/logs/refs
8.0K    ./.git/logs
 40K    ./.git/modules/sub_binary/hooks
8.0K    ./.git/modules/sub_binary/info
  0B    ./.git/modules/sub_binary/logs/refs/heads
8.0K    ./.git/modules/sub_binary/logs/refs/remotes/origin
8.0K    ./.git/modules/sub_binary/logs/refs/remotes
8.0K    ./.git/modules/sub_binary/logs/refs
 12K    ./.git/modules/sub_binary/logs
4.0K    ./.git/modules/sub_binary/objects/0a
4.0K    ./.git/modules/sub_binary/objects/1b
2.0M    ./.git/modules/sub_binary/objects/a0
4.0K    ./.git/modules/sub_binary/objects/info
4.0M    ./.git/modules/sub_binary/objects/pack
6.0M    ./.git/modules/sub_binary/objects
  0B    ./.git/modules/sub_binary/refs/heads
8.0K    ./.git/modules/sub_binary/refs/remotes/origin
8.0K    ./.git/modules/sub_binary/refs/remotes
  0B    ./.git/modules/sub_binary/refs/tags
8.0K    ./.git/modules/sub_binary/refs
6.1M    ./.git/modules/sub_binary
6.1M    ./.git/modules
4.0K    ./.git/objects/70
4.0K    ./.git/objects/de
4.0K    ./.git/objects/info
8.0K    ./.git/objects/pack
 20K    ./.git/objects
4.0K    ./.git/refs/heads
  0B    ./.git/refs/tags
4.0K    ./.git/refs
6.2M    ./.git
2.0M    ./sub_binary
8.2M    .

Поскольку я получаю мелкую загрузку и сбрасываю, я думаю, что репо будет содержать только одну копию файлов + рабочий каталог, который будет около 4 мегабайт.

Answer 1

В моем конкретном случае использования я не могу объединить или извлечь из-за двоичных данных. Так что решение довольно простое:

cd sub_module
git fetch --depth 1
git reset --hard origin/master
cd ..
git add sub_module
git commit -m 'updated sub_module'

Answer 2

Поскольку подмодули почти всегда находятся в режиме отсоединенной головки, это не сработает:

git fetch --depth 1
git checkout sub_binary/master

Редактировать:

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