From: Jerry Wang <jerrywang183@yahoo.com>
Date: Thu, 19 Mar 2026 20:32:57 GMT
Subject: Re: [PATCH v6 0/6] repo info: add category/path keys and --path-format
Message-ID: <58874877-D2F4-431E-82FD-722D8A2BC790@yahoo.com>
In-Reply-To: <20260319033641.38458-1-jayatheerthkulkarni2005@gmail.com>

Hi Jay,

Thanks, this is very helpful.

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

> 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