为什么`git checkout`不会自动执行`git submodule update --recursive`? [英] Why doesn't `git checkout` automatically do `git submodule update --recursive`?

查看:199
本文介绍了为什么`git checkout`不会自动执行`git submodule update --recursive`?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

有人请帮我理解git中的子模块。我知道他们在互联网上大肆抨击,但由于我认为git开发人员是聪明人,因此必须有当前行为的原因 - 也许是解决我的问题的一种方法。



所以,我有一个项目和一些子模块。该项目有不同的分支,例如:


  • MyApp_version2

  • MyApp_version3

  • MyApp_version4

  • MyApp_liteversion

  • MyApp_development


  • 我的子模块不会经常更新(可能每周一次),所以我对他们很好未附加自动到子模块库的头部。



    然而,当我检查一个旧的分支 - 因为我需要修复旧版本该软件 - 我也需要更新子模块。



    我为什么需要这样做?



    我会期望git像svn一样工作。当我在我的主要回购库中完成工作时,我希望git能够按照以下方式思考:好的,他现在想要完成他的工作,我可以看到子模块目前处于修订版abc,所以当他在未来某个时候



    我看不到一个你希望子模块停留在当前状态的情况当你回到主存储库的3年时间。但是,这个实现必须有一个理由,对吧?

    我真的很想听听你们是否知道背后的想法,但无论如何我会真的很喜欢解决方案。有没有办法告诉git:我想用这些子模块来完成这项工作,如果我在某个时候回到这个状态,我希望子模块也能以正确的版本检出。



    澄清示例

    我的主存储库是需要使用SSL的应用程序,我发现我添加了一个SSL库(libSSL)作为子模块。

    2010年10月31日,我在主存储库(2fd4e1)中创建一个提交,而子模块指向libSSL版本3(c67a2d)。



    时间过去了,libSSl被更新为34版本,我调整了我的代码,生活很好。

    在2013年5月14日,我为最新版本的libSSL(849ee1)创建了一个新的提交(28fced)和子模块。

    然而,如果我检查out 2fd4e1即使原始提交是使用c67a2d创建的,我的子模块仍将保留在849ee1。 Git知道我使用c67a2d进行了原始提交,并且我没有看到您可能需要另一个子模块,而不是原始提交创建的子模块。

    解决方案

    这听起来像你想要做的事情可以通过新的 - gcu v2.13 - recurse-submodules 选项 git checkout 。从 git-checkout 手册页:


    - [no-]递归-submodules使用--recurse子模块将根据超级项目中记录的提交更新所有已初始化的子模块的内容。如果子模块中的本地修改将被覆盖,则除非使用-f,否则检出将失败。如果没有使用(或--no-recurse-submodules),则子模块的工作树将不会更新。

    另请参阅此相关的有关该新选项的git邮件列表消息

    Someone please help me understand submodules in git. I know they are getting a lot of bashing around the internet but since I assume the git developers are smart people there must a reason for the current behavior - and maybe a way to work around my problem.

    So, I have a project and some submodules. The project have different branches, like:

    • MyApp_version2
    • MyApp_version3
    • MyApp_version4
    • MyApp_liteversion
    • MyApp_development

    My submodules doesn't update that often (maybe once a week) so I'm fine with them not being attached to the head of the submodule repository automatically.

    However, when I check out an old branch - because I need to fix a bug in an old version of the software - I also need to update the submodules.

    Why do I need to do this?

    I would expect git to work like svn. When I commit my work in my main repo I would expect git to think something along these lines: "OK, he wants to commit his work now. I can see the submodules are currently at revision abc so when he at some point in the future get's back to this commit he probably wants the submodules at the same revision again."

    I can not see a single case where you would want the submodules to stay at the current revision while you go back 3 years in your main repository. However, there must be a reason for this implementation, right?

    I would really like to hear if any of you know the thoughts behind this, but in any case I would really like a solution. Is there a way to tell git: "I want to commit this work with these submodules. If I at some point go back to this state I want the submodules to be checked out at the correct version as well."

    Example for clarification

    My main repository is an application which needs to use SSL, and I find a SSL library (libSSL) I add as a submodule.

    On Oct. 31 2010 I create a commit in my main repository (2fd4e1) while the submodule points to libSSL version 3 (c67a2d).

    Time passes, libSSl gets updated to version 34, I adapt my code, life it good.

    On May 14 2013 I create a new commit (28fced) and submodule points to the most recent version of libSSL (849ee1).

    However, if I check out 2fd4e1 my submodule will stay at 849ee1 even though the original commit was created with c67a2d. Git knows I made the original commit with c67a2d and I don't see how you could possibly want a another submodule than the one the original commit was created with.

    解决方案

    It sounds like what you want to do can be achieved from git v2.13 on with the new --recurse-submodules option of git checkout. From the git-checkout manual page:

    --[no-]recurse-submodules

    Using --recurse-submodules will update the content of all initialized submodules according to the commit recorded in the superproject. If local modifications in a submodule would be overwritten the checkout will fail unless -f is used. If nothing (or --no-recurse-submodules) is used, the work trees of submodules will not be updated.

    See also this relevant git mailing list message about that new option.

    这篇关于为什么`git checkout`不会自动执行`git submodule update --recursive`?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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