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, 23:45 UTC
Message-ID
<CAPig+cSUT3B1OQLatvfnbyRezWm68AzcdhmkiFhnJ3T5Hs=x_w@mail.gmail.com>
In-Reply-To
<CAPig+cTwmBViAGELF69mkYNoz+S-YW5-dcYuNfGeF-wob-=v9Q@mail.gmail.com>
On Sun, Dec 19, 2021 at 6:30 PM Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 19 quoted lines
> On Sun, Dec 19, 2021 at 5:51 PM <rsbecker@nexbridge.com> wrote:
> >         worktree->is_bare = (is_bare_repository_cfg == 1) ||
> >                 is_bare_repository();
> >
> > the == 1 comparison should not be done for boolean-style variables. It is an int, but initialized to -1. Unless -1 and 1 mean different things, but that is not really documented.
>
> `is_bare_repository_cfg` is not exactly a boolean; it's a tristate,
> with -1 meaning "not yet determined". I didn't, at the time, closely
> follow the discussion[1] of the particular bit of code you're
> questioning, but the `== 1` was mentioned at least a couple times,
> once in review by Junio[2], and then in the extra patch commentary by
> "jtan" when he submitted v2[3]. Anyhow, if I'm following the original
> discussion correctly, then the usage, `== 1` (or the equivalent `> 0`)
> is probably correct, and that treating it as a simple boolean (where
> -1 is true, too) would be undesirable. (Of course, I haven't traced
> through the init code at all, so I don't even know if it can ever be
> -1 at this point.) Five existing consumers of this global variable use
> `== 1`, and only two use `> 0`, so this usage is at least reasonably
> consistent with other parts of the project.

Thinking on it a bit more and re-reading jtan's commit message[1], it seems that it can be -1 at this point if `core.bare` is not set in configuration, as indicated at the end of his commit message:

   In order to avoid that, also check core.bare when setting is_bare. If
   core.bare=1, trust it, and otherwise, use is_bare_repository().
It does make me wonder if the code should have been:
    if (is_bare_repository_cfg > 0)
        worktree->is_bare = 1;
    else if (is_bare_repository_cfg < 0)
        worktree->is_bare = is_bare_repository();

in order to respect `core.bare=0`, which the existing code doesn't seem to do, but perhaps I'm misunderstanding the case he was trying to solve related to submodules. Anyhow, I think that's all a tangent from the original issue raised in this thread by Sean (though I could be wrong about that too).

[1]: https://lore.kernel.org/git/20190419172128.130170-1-jonathantanmy@google.com/
Previous: Eric SunshineNext: rsbecker@nexbridge.com
Message 11 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.