git submodule init and redundant data in .gitmodules/.git/config

Hi,

I am starting to learn submodules and hit the first state of confusion when I encountered git-submodule init:

After git-submodule add, I find in my repository a .gitmodules file as well as the newly-cloned submodule. I can call git-submodule status on it to get the HEAD hash. The .gitmodules file has a stanza for each submodule, linking remote url to local path, e.g.:

  [submodule "foo"]
    path = foo
    url = ../foo.git

The manpage then talks about git-submodule init:

    init
      Initialize the submodules, i.e. register in .git/config each
      submodule name and url found in .gitmodules. The key used in
      .git/config is submodule.$name.url. This command does not
      alter existing information in .git/config.

When I run git-submodule init, the following stanza gets added to .git/config:

  [submodule "foo"]
    url = ../foo.git

Unless I call init, I cannot use git-submodule update.

But looking at the two stanzas, it strikes me that the remote url of the submodule is duplicated and detached, creating redundant data which may become desynchronised.

Why is this?

What is the reason for git-submodule init and moving the data to .git/config?

Thanks,

On Wed, Aug 15, 2007 at 06:20:05PM +0200, martin f krafft wrote:

The (most appropriate) URL from which to get updates of a submodule may be different for different people and therefore has to be stored in .git/config. It was then decided that the default value for this URL should be stored in .gitmodules. git submodule init simply initializes the URL using this default value. You are free to not call git submodule init and set a (more) appropriate URL manually.

skimo

also sprach Sven Verdoolaege <skimo@kotnet.org> [2007.08.15.1838 +0200]:

Ah. I shall prepare a patch against the manpage to make this more clear then. Thanks for your explanation.

I have one open question though: why require init? It makes perfect sense to allow for a local override, but unless I need to override it, git-submodule update should really just keep using the default, which it does not as far as I can tell from my tests:

piper:/tmp/cdt.tfd29893/co/a> git submodule update piper:/tmp/cdt.tfd29893/co/a> git-submodule init Submodule 'b' (/tmp/cdt.tfd29893/repos/b.git) registered for path 'b' piper:/tmp/cdt.tfd29893/co/a> git submodule update Initialized empty Git repository in /tmp/cdt.tfd29893/co/a/b/.git/ 0 blocks Submodule path 'b': checked out '0c1403bc9e13480e70745b70f79ffb00deb25a8d'

Is there a reason for this or should I try to create a patch, which would make git-submodule consult .gitmodules in addition to config.submodules for all modules not found in config.submodules.

Now if I may go a step further, I'll claim that init is a misnomer, really. Instead, I would suggest to rename it. Here are some thoughts:

  - config
    there is already git-config, and just like git-svn reuses e.g.
    rebase, this would keep the taxonomy compact
  - cpconf
    it does copy the configuration, after all
  - override
    not sure, since it doesn't actually override anything, but sets
    it all up for the user to be able to override the config
  - instconf
    install or instantiate the configuration
  - localise
    overloaded word, but it'd be localising configuration in some
    ways
  - localconf
    hinting at making the configuration local

Comments welcome,

On Thursday 16 August 2007, martin f krafft wrote:

The information in .gitmodules is only a default value for the URL, and not to be actually used. The URL in the config has to exist and will be used for updating. So the config value is not about overriding anything, but is required information.

The URL should not depend on the current revision you have checked out at the moment; otherwise, if the default URL in .gitmodules changed at some point in the history, and you check out some earlier commit in the superproject, the update of the submodule would not work: the submodule project still resides on the new URL, regardless of the old information in .gitmodules at the time of the old commit.

Josef

also sprach Josef Weidendorfer <Josef.Weidendorfer@gmx.de> [2007.08.16.1553 +0200]:

It's not required for git-submodule status.

Fair point. Thanks,

On Thursday 16 August 2007, martin f krafft wrote:

This can show uninitialized submodules, so that's fine.

As the URL in .gitmodules is only an initial default, it probably could be optional: if you work on a supermodule with a submodule of your own, it is easily possible that you have no idea about what a reasonable default of a submodule URL should be at the time you do the first supermodule commit. It makes no sense to have to provide a bogus URL there.

Josef

On 8/16/07, martin f krafft <madduck@madduck.net> wrote:

The purpose of 'init' is to inform git-submodule about which submodules you want to checkout. E.g. for a project with submodules in directories 'a', 'b' and 'c', you could do

$ git submodule init b c $ git submodule update

This would only fetch/checkout the submodules in direcotories 'b' and 'c', while 'git submodule status' would still inform you that there is actually three submodules available.

Note: If you wanted to initialize all three submodules at once, you
could simply do

$ git submodule init

-- larsh