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

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

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

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

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 Shalow Submodules, но в нем не упоминается, как обновить такой подмодуль.

Edit:

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

Для теста у меня есть двоичный файл размером 2 мега, и я клонирую мелко, чтобы создать подмодуль. du -h при начальном клоне после a 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    .

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

Ответ 1

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

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

Ответ 2

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

git fetch --depth 1
git checkout sub_binary/master

Edit:

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