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

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

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Dec 19, 2021, 20:16 UTC
Message-ID
<e992d4b4-f9e2-a8f9-22da-e9d342c7bede@sunshineco.com>
In-Reply-To
<CABceR4bZmtC4rCwgxZ1BBYZP69VOUca1f_moJoP989vTUZWu9Q@mail.gmail.com>
On 12/18/21 11:46 AM, Sean Allred wrote:
Show 20 quoted lines
> What did you do before the bug happened? (Steps to reproduce your issue)
> 
>      ~$ git clone --bare https://github.com/git/git.git
>      ~/gitbare$ git config --list --show-origin
>      file:config     core.bare=true
>      ~/gitbare$ git worktree add --no-checkout ../next
>      Preparing worktree (checking out 'next')
>      ~/gitbare$ git config --list --show-origin
>      file:config     core.bare=true
>      ~/gitbare$ cd ../next/
>      ~/next$ git config --list --show-origin
>      file:../gitbare/config    core.bare=true
>      ~/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

As far as I can tell, this is working as designed and as documented[1]. `git rev-parse --is-bare-repository` is supposed to return "true" in the bare repository, and "false" in a worktree. However, you missed the step (discussed in [1]) in which it is your responsibility to move the `core.bare=true` setting from git.git/config to git.git/worktree.config manually after setting `extensions.worktreeconfig=true`.

When `extensions.worktreeconfig` is false, --is-bare-repository special cases `core.bare` to return "false" in a worktree regardless of the setting in git.git/config. When `extensions.worktreeconfig` is true, however, that special-casing behavior is disabled, and --is-bare-repository returns whatever it pulls from the configuration. In this case, it returned the value of `core.bare` from git.git/config since you hadn't moved `core.bare=true` to git.git/worktree.config, which would be local only to the bare repository, and not seen by any worktrees.

[1]: https://git-scm.com/docs/git-worktree#_configuration_file
Show 20 quoted lines
> 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).

Regarding #1, creating worktrees from a bare repository is an explicitly-supported use-case, and we've heard several times on the mailing list from people who take advantage of the ability in automation situations (often in CI setups), as well as from people who use it as a part of their daily workflow (in which they don't consider any particular worktree to be "blessed").

Regarding #2, --is-bare-repository is not so much being fooled as it is being lied to by your configuration which wasn't updated to move `core.bare=true` to git.git/worktree.config. (Granted, it's painful that it's your responsibility to move the setting manually; automating would avoid this sort of confusion.)

Show 10 quoted lines
> 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.
Previous: rsbecker@nexbridge.comNext: Sean Allred
Message 5 of 19 in “Bug report - Can create worktrees from bare repo / such worktrees can fool is_bare_repository()”
  1. Sean AllredDec 18, 2021
  2. rsbecker@nexbridge.comDec 18, 2021
  3. Sean AllredDec 18, 2021
  4. rsbecker@nexbridge.comDec 18, 2021
  5. Eric SunshineDec 19, 2021
  6. Sean AllredDec 19, 2021
  7. rsbecker@nexbridge.comDec 19, 2021
  8. Sean AllredDec 19, 2021
  9. rsbecker@nexbridge.comDec 19, 2021
  10. Eric SunshineDec 19, 2021
  11. Eric SunshineDec 19, 2021
  12. rsbecker@nexbridge.comDec 19, 2021
  13. Eric SunshineDec 20, 2021
  14. Eric SunshineDec 20, 2021
  15. Derrick StoleeDec 20, 2021
  16. Eric SunshineDec 20, 2021
  17. Derrick StoleeDec 20, 2021
  18. Eric SunshineDec 20, 2021
  19. Junio C HamanoDec 20, 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.