[GSOC RFC PATCH] builtin/repo: add path.in-worktree field

[GSOC RFC PATCH] builtin/repo: add path.in-worktree field

[SoutrikDas]

Hi everyone,

In this patch I am trying to provide the equivalent functionality of
'git rev-parse --is-inside-work-tree'
I found that I could either use the 'is_inside_work_tree' inside setup.h
which does not take anything , or use the 'is_inside_dir' from dir.h
and use the worktree directory in the repo variable that the function
is getting. 

I went with the latter because the former was using 'the_repository'
inside. 

My reason behind adding this is because : [1]

> Add path-related values currently obtained through git rev-parse 
> (see “Options for Files” in git-rev-parse documentation): 
> git-dir, common-dir, toplevel, superproject-working-tree

Since its intended for repo to have more path related values, then 
'--is-inside-work-tree' would also make sense. 


Although I am not sure if 'path.in-worktree' is the best name for 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/

Add a 'path.in-worktree' field to 'git repo info' that indicates
whether the current directory is inside the worktree or not.
Equivalent to 'git rev-parse --is-inside-work-tree'.

Signed-off-by: SoutrikDas <valusoutrik@gmail.com>
---
 builtin/repo.c  | 8 ++++++++
 t/t1900-repo.sh | 1 +
 2 files changed, 9 insertions(+)

diff --git a/builtin/repo.c b/builtin/repo.c
index 0ea045abc1..3eb7115208 100644
--- a/builtin/repo.c
+++ b/builtin/repo.c
@@ -1,6 +1,7 @@
 #define USE_THE_REPOSITORY_VARIABLE
 
 #include "builtin.h"
+#include "dir.h"
 #include "environment.h"
 #include "hex.h"
 #include "odb.h"
@@ -61,11 +62,18 @@ static int get_references_format(struct repository *repo, struct strbuf *buf)
 	return 0;
 }
 
+static int get_path_in_worktree(struct repository *repo, struct strbuf *buf)
+{
+	strbuf_addstr(buf, is_inside_dir(repo->worktree) ? "true" : "false");
+	return 0;
+}
+
 /* repo_info_fields keys must be in lexicographical order */
 static const struct field repo_info_fields[] = {
 	{ "layout.bare", get_layout_bare },
 	{ "layout.shallow", get_layout_shallow },
 	{ "object.format", get_object_format },
+	{ "path.in-worktree", get_path_in_worktree },
 	{ "references.format", get_references_format },
 };
 
diff --git a/t/t1900-repo.sh b/t/t1900-repo.sh
index 51d55f11a5..d793d1b8e2 100755
--- a/t/t1900-repo.sh
+++ b/t/t1900-repo.sh
@@ -10,6 +10,7 @@ REPO_INFO_KEYS='
 	layout.bare
 	layout.shallow
 	object.format
+	path.in-worktree
 	references.format
 '
 
-- 
2.52.0

Re: [GSOC RFC PATCH] builtin/repo: add path.in-worktree field

[Lucas Seiki Oshiro]

> Hi everyone,

Hi!

> In this patch I am trying to provide the equivalent functionality of
> 'git rev-parse --is-inside-work-tree'

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 found that I could either use the 'is_inside_work_tree' inside setup.h
> which does not take anything , or use the 'is_inside_dir' from dir.h
> and use the worktree directory in the repo variable that the function
> is getting. 
> I went with the latter because the former was using 'the_repository'
> inside.

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.

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.

> Although I am not sure if 'path.in-worktree' is the best name for it.

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

> 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.

> +static int get_path_in_worktree(struct repository *repo, struct strbuf *buf)
> +{
> + strbuf_addstr(buf, is_inside_dir(repo->worktree) ? "true" : "false");
> + return 0;
> +}
> +
> /* repo_info_fields keys must be in lexicographical order */
> static const struct field repo_info_fields[] = {
> { "layout.bare", get_layout_bare },
> { "layout.shallow", get_layout_shallow },
> { "object.format", get_object_format },
> + { "path.in-worktree", get_path_in_worktree },
> { "references.format", get_references_format },
> };

Ok, the process of adding a new field to repo-info is correct.

> diff --git a/t/t1900-repo.sh b/t/t1900-repo.sh
> index 51d55f11a5..d793d1b8e2 100755
> --- a/t/t1900-repo.sh
> +++ b/t/t1900-repo.sh
> @@ -10,6 +10,7 @@ REPO_INFO_KEYS='
> layout.bare
> layout.shallow
> object.format
> + path.in-worktree
> references.format
> '

Test missing here.

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

Re: [GSOC RFC PATCH] builtin/repo: add path.in-worktree field

[SoutrikDas]

> 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.

Re: [GSOC RFC PATCH] builtin/repo: add path.in-worktree field

[Lucas Seiki Oshiro]

> 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 don't think this is small enough to count as a microproject. A
microproject is something simpler than that. See the microprojects
page [1] for suggestions. They are more straightforward things that
have more chances of being accepted quickly. And since having an accepted
microproject is a mandatory step, you'll probably want it to be merged
as soon as possible.

> 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.

I think that this seems to be easy to do, but the reviewing process
may take some time, so it would be better if you stick to a
one of the selected microprojects [1].

>> 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 ?

Yeah, but then we would need to change all the calls to it, using
the_repository at first. But I really don't know, I'll leave this
discussion for more experienced people.

> 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

You can take a look on how `git rev-parse --is-inside-work-tree` is
being tested today and use it as a base, since
`git repo info path.is-inside-work-tree` would return true or false
in the same situations.

[1] https://git.github.io/SoC-2024-Microprojects/

Re: [GSOC RFC PATCH] builtin/repo: add path.in-worktree field

[Junio C Hamano]

Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> writes:

> A
> microproject is something simpler than that. See the microprojects
> page [1] for suggestions. They are more straightforward things that
> have more chances of being accepted quickly. And since having an accepted
> microproject is a mandatory step, you'll probably want it to be merged
> as soon as possible.

Microproject is to serve as a practice session for a new contributor
to go through the patch submission + getting reviewed + sending
polished version cycle.  It does not have to result in a merge to
the project, but it is essential to get reviewed and respond to
reviews.  How well you work with reviewers is the focus of the
observation, and how complex the problem you tackle is is of much
lessor importance.

> I think that this seems to be easy to do, but the reviewing process
> may take some time, so it would be better if you stick to a
> one of the selected microprojects [1].
>
> [1] https://git.github.io/SoC-2024-Microprojects/

Is https://git.github.io/SoC-2026-Microprojects/ the latest?  The
above URL points at one a few years old.

Anyway, this list however might want a bit of updating.

 * I personally feel that "run_command*() to internal call" is way
   too involved for a microproject.  All the low-hanging frutis have
   already been picked in this area, I think.  That is why this does
   not appear in the list of microproject ideas in more recent
   years.

 * People seem to be finding more instances of "test -X" to replace
   with test_path_is_* helpers, so that would be fine to keep for
   now.

 * Ditto for "do not place git upstream of a pipe".

 * "Do not use signed int for collection of flag bits" may have
   outlived its usefulness, as it seems we are pushing more and more
   uses of enum for collection of flag bits.

Re: [GSOC RFC PATCH] builtin/repo: add path.in-worktree field

[Lucas Seiki Oshiro]

> Microproject is to serve as a practice session for a new contributor
> to go through the patch submission + getting reviewed + sending
> polished version cycle.  It does not have to result in a merge to
> the project, but it is essential to get reviewed and respond to
> reviews.  How well you work with reviewers is the focus of the
> observation, and how complex the problem you tackle is is of much
> lessor importance.
> 
>> I think that this seems to be easy to do, but the reviewing process
>> may take some time, so it would be better if you stick to a
>> one of the selected microprojects [1].
>> 
>> [1] https://git.github.io/SoC-2024-Microprojects/
> 
> Is https://git.github.io/SoC-2026-Microprojects/ the latest?  The
> above URL points at one a few years old.

Oops. I've trusted by browser history and pasted the link that I
during my application.

Thanks for correcting me.

Re: [GSOC RFC PATCH] builtin/repo: add path.in-worktree field

[SoutrikDas]

> I don't think this is small enough to count as a microproject. A
> microproject is something simpler than that. See the microprojects
> page [1] for suggestions. They are more straightforward things that
> have more chances of being accepted quickly. And since having an accepted
> microproject is a mandatory step, you'll probably want it to be merged
> as soon as possible.

My bad, by microproject I meant this : 

> GSoc 2026 Idea : Improve the new git repo command
>
> Getting started: Build Git from source, experiment with git repo info 
> and git repo structure commands, study the implementation in builtin/repo.c,
> review the initial GSoC proposal and discussions, compare functionality
> with git rev-parse and identify gaps, and submit a *micro-patch to 
> demonstrate familiarity with the codebase*.

I guess I misunderstood, I thought a relevant micropatch to the project
idea area ( ie repo.c ) had to be submitted along with a general microproject.

I did submit one code microproject [1] and a doc-fix [2]

> I think that this seems to be easy to do, but the reviewing process
> may take some time, so it would be better if you stick to a
> one of the selected microprojects.

Now since a microproject in the gsoc idea domain is not mandatory ... 
I think it would be okay to start on this ? 
Regardless of it being fully reviewed, I feel like I should do some work
on repo.c before writing a gsoc proposal. That way I can better formulate
a timeline, maybe.

> Yeah, but then we would need to change all the calls to it, using
> the_repository at first. But I really don't know, I'll leave this
> discussion for more experienced people.

Alright.

> You can take a look on how `git rev-parse --is-inside-work-tree` is
> being tested today and use it as a base, since
> `git repo info path.is-inside-work-tree` would return true or false
> in the same situations.

Right, I dont know why I didn't do that, I will do that and send a patch v2

[1] : 20260209172445.39536-1-valusoutrik@gmail.com
[2] : pull.2187.git.git.1770293021383.gitgitgadget@gmail.com

Re: [GSOC RFC PATCH] builtin/repo: add path.in-worktree field

[Kaartic Sivaraam]

Hi Junio,

On 27/02/26 04:03, Junio C Hamano wrote:
> Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> writes:
> Is https://git.github.io/SoC-2026-Microprojects/ the latest?  The
> above URL points at one a few years old.
> 
> Anyway, this list however might want a bit of updating.
> 
>   * I personally feel that "run_command*() to internal call" is way
>     too involved for a microproject.  All the low-hanging frutis have
>     already been picked in this area, I think.  That is why this does
>     not appear in the list of microproject ideas in more recent
>     years.
> 
>   * People seem to be finding more instances of "test -X" to replace
>     with test_path_is_* helpers, so that would be fine to keep for
>     now.
> 
>   * Ditto for "do not place git upstream of a pipe".
> 
>   * "Do not use signed int for collection of flag bits" may have
>     outlived its usefulness, as it seems we are pushing more and more
>     uses of enum for collection of flag bits.
> 

Thank you for your suggestions. We've tried to tweak the micro-project
page to remove the stale ones.

   https://git.github.io/SoC-2026-Microprojects/

Feel free to let us know if you have any further suggestions.

--
Sivaraam