Why does adding an existing repo as a submodule modify .git/config?

(I posted this question below on http://stackoverflow.com/questions/6083357/why-does-adding-an-existing-repo-as-a-submodule-modify-git-config and was recommended to ask the mailing list)

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 git@git.server: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 git@git.server:submodule.git
$ git submodule add git@git.server:submodule.git
$ cat .git/config
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
[submodule "submodule"]
    url = git@git.server: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.

I'm aware this is intentional behavior (https://github.com/git/git/commit/c2f939170c65173076bbd752bb3c764536b3b09b), but I don't understand why.

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

Am 22.05.2011 22:02, schrieb Christopher Wilson:

Hmm, this looks like an inconsistency to me too. It would be great to hear about the background, so I added Mark to the CC, maybe he can shed some light.

On 05/23/2011 02:43 PM, Jens Lehmann wrote:

I think the comment in c2f939170c651 describes the reasoning well enough. (You may disagree with the reasoning, but that is a different matter :^).

Mark

On 5/23/11 6:19 PM, Mark Levedahl wrote:

Mark, thanks for the reply. Maybe I'm a bit daft, but I'm still a little confused by your comment in the commit :)

I've included your commit message below with my questions interlaced.

C: "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."

Q: Why don't we go through "git submodule init" to register the
submodule?  Isn't that the whole point of having a separate "submodule
init" command, to register the module in .git/config?

C: "Thus, the submodule's origin repository URL is not stored in
.git/config, and no subsequent submodule operation will ever do so."

I'm not sure this is true.  For example:

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

# At this point, I opened up .git/config in an editor and removed the entire submodule section.

$ cat .git/config
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
$ git submodule init
$ cat .git/config
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
[submodule "submodule"]
    url = git@git.server:submodule.git

Q: As far as I can tell, a subsequent submodule operation (git submodule
init) has stored the submodule's origin repository URL in .git/config.
Can you elaborate on what you meant by the statement "no subsequent
submodule operation will ever do so"?

C: "In this case, assume the URL the user supplies to "submodule add" is
the one that should be registered, and do so."

Q: Can you elaborate on why a 2 step "git submodule add" + "git
submodule init" wasn't sufficient?  What is the reason for adding this
functionality into the "git submodule add" command, when "git submodule
init" does the same job?

Again, sorry if I'm asking dumb questions... :) Just want to understand the context for your commit.

On 05/24/2011 03:06 AM, Christopher Wilson wrote:

git-submodule.sh has evolved considerably over the last couple of years, and the behaviour of submodule-init on an already existing module may well be different.

However, while you could then change submodule-add to not register the submodule, you would now have the condition of having a submodule that is checked out in the current tree but *not* registered in .git/config. This is the key: .git/config is modified to include all submodules that are checked out in your current tree. If you add a remote submodule, that submodule is not checked out in your current tree so no entry is created in .git/config, while adding one that is already checked out in place does modify .git/config. I see no inconsistency here.

Mark

On Tue, May 24, 2011 at 6:06 PM, Mark Levedahl <mlevedahl@gmail.com> wrote:

Isn't this exactly what "git submodule add" currently does for submodules that are NOT added in place?

For example:

$ mkdir testing
$ cd testing
$ git init
...
$ ls
# nothing in the working tree
$ git submodule add git@git.server:submodule.git
Cloning into submodule...
remote: Counting objects: 13, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 13 (delta 2), reused 0 (delta 0)
Receiving objects: 100% (13/13), done.
Resolving deltas: 100% (2/2), done.
$ ls
submodule
$ cat .git/config
[core]
   repositoryformatversion = 0
   filemode = true
   bare = false
   logallrefupdates = true
   ignorecase = true
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#	new file:   .gitmodules
#	new file:   submodule
#

As you can see, if I create a new repo and check out a remote submodule, that submodule IS actually checked out in my current tree and no entry is created in .git/config. Although the remote submodule has been added to .gitmodules, it takes "git submodule init" to actually register it into .git/config:

$ git submodule init
Submodule 'submodule' (git@git.server:submodule.git) registered for
path 'submodule'
$ cat .git/config
[core]
   repositoryformatversion = 0
   filemode = true
   bare = false
   logallrefupdates = true
   ignorecase = true
[submodule "submodule"]
   url = git@git.server:submodule.git

The inconsistency is that when adding a submodule in place, the registration into .git/config takes place, but when adding a remote submodule that is not in the working tree, the registration does not happen. In the second case, don't you end up with exactly what you said we're trying to avoid, which is "the condition of having a submodule that is checked out in the current tree but *not* registered in .git/config"?

Chris

Am 25.05.2011 05:11, schrieb Christopher Wilson:

That is the inconsistency this thread is about. Thanks Christopher for bringing that up and to Mark for explaining the rationale for updating the url in .git/config. I really agree with what Mark said there and also concur with Christopher that a "git submodule add" should always update the url in .git/config, no matter if it is an already existing repo being added or a freshly cloned one.

But unfortunately there is more to it than just adding a
	git config submodule."$path".url "$realrepo"
to the module_clone branch in cmd_add() because that makes tests break
where "git submodule init" doesn't copy the "update" settings into
.git/config anymore as it already finds an url configured there and
thinks there is nothing to do. I'm looking into fixing that right now,
so stay tuned ...