如何在不增加主回购大小的情况下更新浅克隆子模块 [英] How to update a shallow cloned submodule without increasing main repo size

查看:195
本文介绍了如何在不增加主回购大小的情况下更新浅克隆子模块的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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



我可以正确设置浅度子文件夹,但如果二进制回购(完整历史记录)发生更改,我不知道如何更新到最新版本。



我的回购结构与此类似:

  main_project 
sub_binary
其他项目文件
...

这里是允许的命令我有一个浅的子模块:

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

这可以起作用,并且sub_binary被固定到正确的修订版。



如何将浅层子模块 sub_binary (并将其记录在main_repo中)更新为最新版本(仅限最新版本) if远程库回购得到更新?



注意:


  • 如果我在初始子模块设置中的sub_binary中执行git日志,我会得到t他预计一次提交的历史。
  • 当我尝试在中执行 git pull --depth 1 时,
  • sub_binary ,我得到一个合并错误:自动合并失败;修复冲突,然后提交结果。
  • :VonC对Git Shallow Submodules的回答,但没有提及如何更新这样的子模块。


编辑:

在大量的git学习之后,我已经能够更新子模块(查看我自己的答案)。但是仍然存在这样的问题,即在获取新版本时主repo会增长。



对于测试,我有一个二进制文件,大小为2 meg,我克隆得很浅创建子模块。
du -h git子模块更新之后的初始克隆中--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_bi nary / 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.0 K ./.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.0 K ./.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/ [R efs / 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个兆字节。

解决方案

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

$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ g $重置 - - hard origin / master
cd ..
git add sub_module
git commit -m'updated sub_module'


I want to convert to git an existing codebase which has big binary library files in it. The library files are external (vendor) dependencies. These binaries are only needed to link the final application. The size of these binaries is huge (2.2 Gig), so in order to reduce the main repo size (and not have to unduly grow the main repo size), I would like to host the binaries in a git repo and use a submodule to reference only the latest version of the library binaries.

I can setup correctly the shallow subrepo, but I do not know how to update to the latest version if the binary repo (with full history) changes.

The repo structure I have is similar to this:

main_project
    sub_binary
    other project files
    ...

here are the commands that allowed me to have a shallow submodule:

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

This works and the sub_binary is pinned to the correct revision.

How do I update the shallow submodule sub_binary (and record this in the main_repo) to the latest version (and only the latest revision) if the remote library repo gets updated?

Notes:

  • if I do a git log in sub_binary in the initial submodule setup, I get the expected history of one commit.
  • when I try to do a git pull --depth 1 in sub_binary, I get a merge error: Automatic merge failed; fix conflicts and then commit the result.
  • I am using git 1.8.4
  • I have read VonC's answer to Git Shallow Submodules, but it does not mention how to update such a submodule.

Edit:

I have been able to update the submodule after a lot of git learning (see my own answer). But there is still the issue that the main repo grows as new versions are fetched.

For a test, I have a binary file, 2 meg in size and I clone shallowly to create a submodule. du -h at initial clone after 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 after two or three update cycles:

 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    .

Since I fetch shallowly and reset, I would think that the repo would contain only one copy of the files + the working dir which would be around 4 megs.

解决方案

In my particular use case, I cannot merge or pull because of binary data. So the solution is quite simple:

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

这篇关于如何在不增加主回购大小的情况下更新浅克隆子模块的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆