From: Chris Packham Date: Tue, 07 May 2013 08:01:04 GMT Subject: Re: Fwd: Uninit'ed submodules Message-ID: <5188B4C0.50206@gmail.com> In-Reply-To: <51880191.2070809@web.de> 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.