That makes sense. I agree that checking only repo_get_work_tree(repo) == NULL is too weak, and the "git -C <nonbare>/.git" case is a good example of that.
I'll keep the linked-worktree / separate-git-dir coverage patch separate. For layout.bare, I'll first add tests to pin down the intended semantics, then follow up with a small repo-aware fix, likely with a repo_is_bare() helper if that turns out to be the right shape.
Thanks, Jialong
Show 41 quoted lines
> On Mar 18, 2026, at 23:36, K Jayatheerth <jayatheerthkulkarni2005@gmail.com> wrote:
>
>> While reading the current `git repo info` implementation, I noticed that
>> `layout.bare` is still implemented via `is_bare_repository()` in
>> `builtin/repo.c`.
>>
>> At first I thought this might be a small repository-awareness cleanup,
>> since the `repo info` field callbacks already receive a `struct
>> repository *`. But after tracing it further, it seems the current
>> `is_bare_repository()` semantics are not equivalent to simply checking
>> whether `repo_get_work_tree(repo)` is NULL.
>
> Hmph, this was an idea I explored few days ago
> But I do agree the repo->worktree == NULL method has multiple flaws
>
> For example
>
> test_expect_success 'layout.bare is false even when run from inside .git' '
> git init nonbare-dot-git &&
> echo "layout.bare=false" >expect &&
>
> git -C nonbare-dot-git/.git repo info layout.bare >actual &&
> test_cmp expect actual
> '
>
> I cooked up a test like this and it failed
> I have since been exploring config.c and parse.c.
> specifically the if repo_config_get_bool()
>
> I think there are few other checks we need to do on top of
> repo->worktree to be completely sure that the given repo is in fact bare.
> Also instead of using repo->worktree I think we can use repo_get_work_tree(repo)
> Why recreate the logic when we have a getter ;)
>
> I am convinced that we need a helper
> repo_is_bare is a good name too.
>
> Thanks for exploring this :)
>
> Regards,
> - Jayatheerth