Hi folks! See the following bug report. Let me know if anything is
unclear -- in all honesty, I neglectfully `git worktree remove
--force`'d the first one I 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)
~$ git clone --bare https://github.com/git/git.git
---clip---
~/gitbare$ git config --list --show-origin
file:config core.repositoryformatversion=1
file:config core.filemode=false
file:config core.bare=true
file:config core.ignorecase=true
file:config remote.origin.url=https://github.com/git/git.git
~/gitbare$ git worktree add --no-checkout ../next
Preparing worktree (checking out 'next')
~/gitbare$ git config --list --show-origin
file:config core.repositoryformatversion=1
file:config core.filemode=false
file:config core.bare=true
file:config core.ignorecase=true
file:config remote.origin.url=https://github.com/git/git.git
~/gitbare$ cd ../next/
~/next$ git config --list --show-origin
file:../gitbare/config core.repositoryformatversion=1
file:../gitbare/config core.filemode=false
file:../gitbare/config core.bare=true
file:../gitbare/config core.ignorecase=true
file:../gitbare/config remote.origin.url=https://github.com/git/git.git
~/next$ git rev-parse --is-bare-repository
false
~/next$ git config extensions.worktreeconfig true
~/next$ git rev-parse --is-bare-repository
true
~/next$ git config --unset extensions.worktreeconfig
~/next$ git rev-parse --is-bare-repository
false
I actually found this situation (and narrowed it to the above) by
trying to perform a sparse-checkout in the worktree. It appears
sparse-checkout by default uses a worktree-specific config (which
does make sense).
What did you expect to happen? (Expected behavior)
I expected one of the following to happen:
1. I should have been blocked from creating a worktree from a bare
repository.
2. is_bare_repository() shouldn't be fooled by this situation,
assuming it's valid.
All things being equal, I would more expect to have been blocked
from creating a worktree from a bare repository. Personally, this
bare repo + worktree setup doesn't not align with my experience so
far with how bare repos are normally used (i.e., as a convenience
for centralized remotes that will never be doing a checkout).
What happened instead? (Actual behavior)
is_bare_repository() is fooled and I'm prevented from performing
any operation that requires a worktree (like performing a sparse
checkout).
What's different between what you expected and what actually happened?
is_bare_repository() is fooled into thinking the worktree is not a
worktree / I'm able to create a worktree from a bare repo.
Anything else you want to add:
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.34.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43
UTC 2020 x86_64
compiler info: gnuc: 9.3
libc info: glibc: 2.31
$SHELL (typically, interactive shell): /bin/bash
[Enabled Hooks]
not run from a git repository - no hooks to show
Best,
-Sean
