【问题标题】:How to update a shallow cloned submodule without increasing main repo size如何在不增加主仓库大小的情况下更新浅克隆子模块
【发布时间】:2013-12-06 22:26:33
【问题描述】:

我想将现有的代码库转换为 git,其中包含大型二进制库文件。库文件是外部(供应商)依赖项。这些二进制文件只需要链接最终的应用程序。这些二进制文件的大小很大(2.2 Gig),所以为了减少主仓库的大小(并且不必过度增加主仓库的大小),我想将二进制文件托管在 git repo 中并使用子模块来仅引用最新版本的库二进制文件。

我可以正确设置浅子存储库,但如果二进制存储库(具有完整历史记录)发生更改,我不知道如何更新到最新版本。

我的回购结构是这样的:

main_project
    sub_binary
    other project files
    ...

以下是允许我拥有浅子模块的命令:

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

这可行,并且 sub_binary 被固定到正确的版本。

如果远程库 repo 得到更新,我如何将浅子模块 sub_binary(并将其记录在 main_repo 中)更新到最新版本(并且仅是最新版本)

注意事项:

  • 如果我在初始子模块设置中执行 git log in sub_binary,我会得到预期的一次提交历史记录。
  • 当我尝试在sub_binary 中执行git pull --depth 1 时,出现合并错误:自动合并失败;修复冲突,然后提交结果。
  • 我正在使用 git 1.8.4
  • 我读过VonC's answer to Git Shallow Submodules,但没有提到如何更新这样的子模块。

编辑:

经过大量 git 学习后,我已经能够更新子模块 (see my own answer)。但是仍然存在随着获取新版本而主 repo 增长的问题。

为了测试,我有一个 2 兆大小的二进制文件,我通过浅层克隆来创建一个子模块。 du -hgit 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    .

由于我浅层获取并重置,我认为 repo 将仅包含文件的一份副本 + 大约 4 兆的工作目录。

【问题讨论】:

    标签: git git-submodules


    【解决方案1】:

    在我的特定用例中,由于二进制数据,我无法合并或拉取。所以解决方法很简单:

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

    【讨论】:

    • 您在此处的回答以及评论不清楚您是否成功地仅保留了最新版本。这 看起来 就像您只保留 1 次提交,但您的编辑表明 repo 仍在保留所有历史记录。你有想过这个吗?
    【解决方案2】:

    由于子模块几乎总是处于分离头模式,那么这不会起作用:

    git fetch --depth 1
    git checkout sub_binary/master
    

    编辑:

    这个线程here 表示git pull 应该可以工作。遥控器的头部和子模块的头部之间是否存在线性历史?

    【讨论】:

    • 目的是在主存储库的每次更新中只有一个版本,即最新版本。提取会带来额外的历史记录,由于文件的大小,我不想要这些。是的,历史是线性的;但我不认为这是一个问题/要求,因为我真的只想在 main_project 中一次修改一个。
    猜你喜欢
    • 2018-12-02
    • 2016-02-16
    • 2019-10-25
    • 2017-04-25
    • 2012-12-31
    • 1970-01-01
    • 2020-08-08
    • 1970-01-01
    相关资源
    最近更新 更多