On 07/05/13 07:16, Jens Lehmann wrote: > Am 06.05.2013 02:19, schrieb Chris Packham: >> This did get me thinking. Why does an uninitialized submodule need to >> have an empty directory? If it didn't the maintainer in question >> probably would have realized that he needed to run "git submodule >> update --init" when his "cd submodule" command failed. >> >> I'm guessing there is a good reason for the empty directory - perhaps >> so that git can notice the fact that it exists in the worktree but is >> out of date? If it does need to have some presence in the worktree >> why not as a file? That way the cd command would still fail (albeit >> with a different error) providing the necessary indication to the >> user. The submodule update --init could then change from file -> dir >> when it actually gets populated. > > Hmm, to me an empty directory is the natural representation of an > unpopulated submodule, but I see why that made it hard for your > maintainer to notice the fact that the submodule was uninitialized. > I suspect changing an unpopulated submodule to be represented by a > file will surprise quite some users (some of which will probably > come up with perfectly valid use cases such a change will break). > > What about the following: Today's Git completely ignores empty > submodule directories, but I think that when the recursive checkout > support is there, the "submodule.autoupdate" flag - which I believe > should control that behavior - could also make those empty submodule > directories show up in "git status" as being unpopulated (after all > they are configured to be updated automatically, so not having them > populated is something Git should show). Would something like this > have helped here? > > Until then I can only propose to establish a best practice of using > "git clone --recurse-submodules" in these situations to avoid the > problem you described. > Yeah I think training people to use --recurse-submodules is probably the best thing we can do with the current version of git on our developers work stations. There is a bit of an issue when we add a new submodule (people aren't used to using submodule update --init), but that isn't a frequent occurrence. The recursive checkout sounds like something we'd benefit from. -- 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