Re: Fwd: Uninit'ed submodules

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