Re: Bare repositories in the working tree are a security risk

[Glen Choo <chooglen@google.com>]

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