RE: Bug report - Can create worktrees from bare repo / such worktrees can fool is_bare_repository()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On December 18, 2021 11:47 AM, Sean Allred wrote:
> 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

My thoughts:

1. I think it is legitimate to create a worktree from a bare repository. The worktree is using its own working directory/index and does not require anything from the bare repo.
2. You ran is_bare_repository from next, which was in your worktree - not a bare repo, so that answer actually makes sense.

I'm not sure whether this is an expected use case but it does make sense to be one. If you typically work in worktrees and write scripts under that assumption, not having to worry about being in the non-worktree part of a clone makes sense. So creating a worktree off a bare repo is not a bad thing, assuming everything else is correct.

Just my $0.02,
-Randall




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux