builtin/init-db: handle bare clones when core.bare set to false
commit75555676ad3908b0f847a9ae154c35e12114c82f
authorbrian m. carlson <sandals@crustytoothpaste.net>
Wed, 10 Mar 2021 01:11:20 +0000 (10 01:11 +0000)
committerJunio C Hamano <gitster@pobox.com>
Wed, 10 Mar 2021 23:06:48 +0000 (10 15:06 -0800)
tree30d4d80bb69e8c1091cbdb5e0e7a5dad2d76a90f
parent71ca53e8125e36efbda17293c50027d31681a41f
builtin/init-db: handle bare clones when core.bare set to false

In 552955ed7f ("clone: use more conventional config/option layering",
2020-10-01), clone learned to read configuration options earlier in its
execution, before creating the new repository.  However, that led to a
problem: if the core.bare setting is set to false in the global config,
cloning a bare repository segfaults.  This happens because the
repository is falsely thought to be non-bare, but clone has set the work
tree to NULL, which is then dereferenced.

The code to initialize the repository already considers the fact that a
user might want to override the --bare option for git init, but it
doesn't take into account clone, which uses a different option.  Let's
just check that the work tree is not NULL, since that's how clone
indicates that the repository is bare.  This is also the case for git
init, so we won't be regressing that case.

Reported-by: Joseph Vusich <jvusich@amazon.com>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/init-db.c
t/t5606-clone-options.sh