> I wonder if all we need to do is make setup.c a little smarter - we > recognize bare repos, but *only* if they are contained in a directory > named `.git/`. This should fix "git init" I think, because even though > we'd ignore "./ (bare)", we'd recognize `../.git/` and we get the right > behavior again. > > > It is a separate matter if it makes sense to allow creating a new > > repository inside a bare repository (it does---that is what the > > modern submodule layout uses), or to allow an alias to help doing so > > defined in the top-level bare repository (it probably does---the > > end-user may want to have a handy way to customize how submodules > > are configured). But it seems to tell us that with today's external > > interface we have for "git init", we cannot take configuration from > > a shallower level and use it to drive "git init" to create a new > > repository at a deeper level. Hah, I forgot that submodules are stored as `.git/modules/foo` and not `.git/modules/foo/.git`, so this doesn't preserve the existing behavior for submodules nested > 1 level.
