为什么将现有存储库添加为子模块会修改 .git/config？

发布于 2024-11-08 12:59:44 字数 1433 浏览 4 评论 0原文

如果我添加当前不存在的子模块，则不会将任何子模块信息添加到 .git/config 中。

$ mkdir testing
$ cd testing
$ git init
$ git submodule add [email protected]:submodule.git
$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true

但是，如果我添加当前作为子模块存在的存储库，则 url 将添加到 .git/config 中：

$ mkdir testing
$ cd testing
$ git init
$ git clone [email protected]:submodule.git
$ git submodule add [email protected]:submodule.git
$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
[submodule "submodule"]
    url = [email protected]:submodule.git

我会假设在这两种情况下，git submodule add只会修改 .gitmodules，并且 git submodule init 会更新项目的 .git/config。

为什么在第二种情况下修改了 .git/config 而不是第一种情况？有人可以解释这种行为的合理性吗？

原文

If I add a submodule that does not currently exist, no submodule information is added to .git/config.

$ mkdir testing
$ cd testing
$ git init
$ git submodule add [email protected]:submodule.git
$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true

However, if I add a repo that currently exists as a submodule, the url is added to .git/config:

$ mkdir testing
$ cd testing
$ git init
$ git clone [email protected]:submodule.git
$ git submodule add [email protected]:submodule.git
$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
[submodule "submodule"]
    url = [email protected]:submodule.git

I would have assumed that in both cases, git submodule add would have only modified .gitmodules, and that git submodule init would have updated the project's .git/config.

Why is .git/config modified in the second case but not the first? Can somebody explain the rational for this behavior?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

や三分注定 2024-11-15 12:59:44

这看起来确实很奇怪。在此提交中引入了该行为：

commit c2f939170c65173076bbd752bb3c764536b3b09b
Author: Mark Levedahl <[email protected]>
Date:   Wed Jul 9 21:05:41 2008 -0400

    git-submodule - register submodule URL if adding in place

    When adding a new submodule in place, meaning the user created the
    submodule as a git repo in the superproject's tree first, we don't go
    through "git submodule init" to register the module.  Thus, the
    submodule's origin repository URL is not stored in .git/config, and no
    subsequent submodule operation will ever do so.  In this case, assume the
    URL the user supplies to "submodule add" is the one that should be
    registered, and do so.

    Signed-off-by: Mark Levedahl <[email protected]>
    Signed-off-by: Junio C Hamano <[email protected]>

更新：您已经指出在下面的评论中，我对此提交消息的原始解释没有任何意义，因此我现在删除了该文本以避免其他人感到困惑。

正如下面的评论中提到的，cdwilson 发布到 git 邮件列表来询问这种不一致问题，因此 Jens Lehman 正在致力于修复 - 该线程可以在这里找到：

http://git.661346.n2.nabble.com/Why-does-adding-an-existing-repo-as-a-submodule-modify-git-config-td6392263.html

This does seem strange. That behaviour was introduced in this commit:

commit c2f939170c65173076bbd752bb3c764536b3b09b
Author: Mark Levedahl <[email protected]>
Date:   Wed Jul 9 21:05:41 2008 -0400

    git-submodule - register submodule URL if adding in place

    When adding a new submodule in place, meaning the user created the
    submodule as a git repo in the superproject's tree first, we don't go
    through "git submodule init" to register the module.  Thus, the
    submodule's origin repository URL is not stored in .git/config, and no
    subsequent submodule operation will ever do so.  In this case, assume the
    URL the user supplies to "submodule add" is the one that should be
    registered, and do so.

    Signed-off-by: Mark Levedahl <[email protected]>
    Signed-off-by: Junio C Hamano <[email protected]>

Update: you've pointed out in the comments below that my original interpretation of this commit message didn't make any sense, so I've removed that text now to avoid confusion for others.

As mentioned in the comments below, cdwilson posted to the git mailing list to ask about this inconsistency, and as a result Jens Lehman is working on a fix - that thread can be found here: