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

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

[Christopher Wilson]

(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?

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

[Jens Lehmann]

Am 22.05.2011 22:02, schrieb Christopher Wilson:
> (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?

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.

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

[Mark Levedahl]

On 05/23/2011 02:43 PM, Jens Lehmann wrote:
> 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.
>
I think the comment in c2f939170c651 describes the reasoning well 
enough. (You may disagree with the reasoning, but that is a different 
matter :^).

Mark

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

[Christopher Wilson]

On 5/23/11 6:19 PM, Mark Levedahl wrote:
> On 05/23/2011 02:43 PM, Jens Lehmann wrote:
>> 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.
>>
> I think the comment in c2f939170c651 describes the reasoning well
> enough. (You may disagree with the reasoning, but that is a different
> matter :^).
> 
> Mark

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.

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

[Mark Levedahl]

On 05/24/2011 03:06 AM, Christopher Wilson wrote:
>>
>> Mark
>
>
> 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?
>

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

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

[Christopher Wilson]

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

> 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.

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

> 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.

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

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

[Jens Lehmann]

Am 25.05.2011 05:11, schrieb Christopher Wilson:
> On Tue, May 24, 2011 at 6:06 PM, Mark Levedahl <mlevedahl@gmail.com> wrote:
> 
>> 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.
> 
> Isn't this exactly what "git submodule add" currently does for
> submodules that are NOT added in place?

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 ...