Makes sense, but this way you're re-writing `is_inside_work_tree`
inside `get_path_in_worktree` but without using the is_inside_work_tree
variable. I don't know what's the cost of doing this.

I also dont know for sure, but the is_inside_work_tree in setup.c has a
lazy cache ie a 'static int inside_work_tree' ... but this lazy cache
as far as I understood, does not survive after a command run. 

I'm not sure if it should be in git-repo-info. I mean, this information
is more related to the current directory than the repository itself.

I see. Very well, I was searching for something small enough to count
as a microproject. If I may ask, can you give some directions ?
I though about doing the group key thing : 

Use the category as key (e.g., git repo info layout would return all 
layout-related values)

But its already on the SoC 2026 Ideas , and I dont know if I should do
it.

Something that I would question here if isn't it possible to make
is_inside_work_tree accept a repository as parameter and then use it
here.

Like change the function in setup.c ? wouldnt that break every call of 
is_inside_work_tree ? Or make a similar function , along with a lazy cache
just for repo.c ? 

I think 'path.is-in-worktree' would be better.

Got it.

Also, I did run t1900-repo.sh and it was failing one test case,
which also ran with an ok when I added the new field to REPO_INFO_KEYS.

[1] : https://git.github.io/SoC-2026-Ideas/

Everything above is not meant to be a commit message. This way, it
should be placed after the scissors mark (---) or in a cover letter.

Got it.

Test missing here.

Yeah ... I missed that. Suppose we were adding this path.is-in-worktree
to repo.c , then would the below test be sufficient ? 
1: cd .git and then checking if path.is-in-worktree is false 
2: cd .. and then checking if path.is-in-worktree is true

Thanks for your interest in contributing to git-repo-info!

Thank you for the feedback and all the encouragement in the other thread
as well.