On Tue, May 24, 2011 at 6:06 PM, Mark Levedahl <mlevedahl@xxxxxxxxx> 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@xxxxxxxxxx: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@xxxxxxxxxx:submodule.git) registered for path 'submodule' $ cat .git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true [submodule "submodule"] url = git@xxxxxxxxxx: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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html