git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: bug: conflicting core.bare setting causes segfault during bare clone

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Mar 3, 2021, 23:59 UTC
Message-ID
<YEAi4OkkNnp+IMJD@camp.crustytoothpaste.net>
In-Reply-To
<D99DD9AD-54E5-4357-BA50-8B9CAE23084E@amazon.com>
On 2021-03-03 at 00:06:01, Vusich, Joseph wrote:
Show 23 quoted lines
> 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
Previous: Vusich, JosephNext: Junio C Hamano
Message 2 of 10 in “bug: conflicting core.bare setting causes segfault during bare clone”
  1. Vusich, JosephMar 3, 2021
  2. brian m. carlsonMar 3, 2021
  3. Junio C HamanoMar 4, 2021
  4. Vusich, JosephMar 4, 2021
  5. builtin/init-db: handle bare clones when core.bare set to falsebrian m. carlson, Mar 8, 2021
  6. Eric SunshineMar 8, 2021
  7. brian m. carlsonMar 8, 2021
  8. builtin/init-db: handle bare clones when core.bare set to falsebrian m. carlson, Mar 10, 2021
  9. Junio C HamanoMar 10, 2021
  10. brian m. carlsonMar 10, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.