On 2021-03-03 at 00:06:01, Vusich, Joseph wrote:
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
> 
> What did you do before the bug happened? (Steps to reproduce your issue)
> 
> $ env | grep GIT
> 
> $ git config --list
> user.email=jvusich@amazon.com
> user.name=Joseph Vusich
> core.bare=false
> 
> $ git clone --bare https://github.com/josephvusich/fixture
> Cloning into bare repository 'fixture.git'...
> zsh: segmentation fault  /opt/local/bin/git clone --bare https://github.com/josephvusich/fixture
> 
> What did you expect to happen? (Expected behavior)
> 
> "git clone --bare" should clone a bare repository, regardless of the core.bare setting in the global config
> 
> What happened instead? (Actual behavior)
> 
> "git clone --bare" causes a segfault if the global gitconfig has core.bare=false

I appreciate the report, and I can reproduce with 45526154a5 from next.
We should definitely not segfault in this case.  I completely agree that
segfaulting is the wrong behavior (because it's always the wrong
behavior for a command-line tool).

I do, however, think we should either ignore core.bare in the global
configuration, if we don't already, or produce an error.  The
documentation says, "If true this repository is assumed to be bare" and
much like we ignore certain other settings outside of .git/config, we
should ignore this one.

I also agree that "git clone --bare" should clone a bare repository
since we'd ignore the global setting.

I'm probably not going to get a chance to look at this before the
weekend, so anyone is free to come up with a patch in the meantime, but
if nobody has gotten to it then, I'll try to send out a patch.

I will admit being a bit interested in how this was discovered, since it
seems like an odd configuration to have, so if you can share, I'd
appreciate it, if only to satisfy my curiosity.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US