{"thread":{"id":"65076","subject":"[GSOC RFC PATCH] builtin/repo: add path.in-worktree field","startedAt":"2026-02-25T19:03:40Z","lastAt":"2026-03-02T18:08:17Z","messageCount":8,"participants":["SoutrikDas","Lucas Seiki Oshiro","Junio C Hamano","Kaartic Sivaraam"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"537126","messageId":"20260225190306.39358-1-valusoutrik@gmail.com","threadId":"65076","inReplyTo":null,"subject":"[GSOC RFC PATCH] builtin/repo: add path.in-worktree field","fromName":"SoutrikDas","fromEmail":"valusoutrik@gmail.com","sentAt":"2026-02-25T19:03:04Z","receivedAt":"2026-02-25T19:03:40Z","isPatch":true,"sender":{"key":"valusoutrik@gmail.com","avatar":"https://avatars.githubusercontent.com/u/56778179?v=4"},"body":"Hi everyone,\n\nIn this patch I am trying to provide the equivalent functionality of\n'git rev-parse --is-inside-work-tree'\nI found that I could either use the 'is_inside_work_tree' inside setup.h\nwhich does not take anything , or use the 'is_inside_dir' from dir.h\nand use the worktree directory in the repo variable that the function\nis getting. \n\nI went with the latter because the former was using 'the_repository'\ninside. \n\nMy reason behind adding this is because : [1]\n\n> Add path-related values currently obtained through git rev-parse \n> (see “Options for Files” in git-rev-parse documentation): \n> git-dir, common-dir, toplevel, superproject-working-tree\n\nSince its intended for repo to have more path related values, then \n'--is-inside-work-tree' would also make sense. \n\n\nAlthough I am not sure if 'path.in-worktree' is the best name for it.\nAlso, I did run t1900-repo.sh and it was failing one test case,\nwhich also ran with an ok when I added the new field to REPO_INFO_KEYS.\n\n[1] : https://git.github.io/SoC-2026-Ideas/\n\nAdd a 'path.in-worktree' field to 'git repo info' that indicates\nwhether the current directory is inside the worktree or not.\nEquivalent to 'git rev-parse --is-inside-work-tree'.\n\nSigned-off-by: SoutrikDas <valusoutrik@gmail.com>\n---\n builtin/repo.c  | 8 ++++++++\n t/t1900-repo.sh | 1 +\n 2 files changed, 9 insertions(+)\n\ndiff --git a/builtin/repo.c b/builtin/repo.c\nindex 0ea045abc1..3eb7115208 100644\n--- a/builtin/repo.c\n+++ b/builtin/repo.c\n@@ -1,6 +1,7 @@\n #define USE_THE_REPOSITORY_VARIABLE\n \n #include \"builtin.h\"\n+#include \"dir.h\"\n #include \"environment.h\"\n #include \"hex.h\"\n #include \"odb.h\"\n@@ -61,11 +62,18 @@ static int get_references_format(struct repository *repo, struct strbuf *buf)\n \treturn 0;\n }\n \n+static int get_path_in_worktree(struct repository *repo, struct strbuf *buf)\n+{\n+\tstrbuf_addstr(buf, is_inside_dir(repo->worktree) ? \"true\" : \"false\");\n+\treturn 0;\n+}\n+\n /* repo_info_fields keys must be in lexicographical order */\n static const struct field repo_info_fields[] = {\n \t{ \"layout.bare\", get_layout_bare },\n \t{ \"layout.shallow\", get_layout_shallow },\n \t{ \"object.format\", get_object_format },\n+\t{ \"path.in-worktree\", get_path_in_worktree },\n \t{ \"references.format\", get_references_format },\n };\n \ndiff --git a/t/t1900-repo.sh b/t/t1900-repo.sh\nindex 51d55f11a5..d793d1b8e2 100755\n--- a/t/t1900-repo.sh\n+++ b/t/t1900-repo.sh\n@@ -10,6 +10,7 @@ REPO_INFO_KEYS='\n \tlayout.bare\n \tlayout.shallow\n \tobject.format\n+\tpath.in-worktree\n \treferences.format\n '\n \n-- \n2.52.0\n\n"},{"id":"537128","messageId":"05C28DD8-251A-4990-BBB2-26C144CAD982@gmail.com","threadId":"65076","inReplyTo":"20260225190306.39358-1-valusoutrik@gmail.com","subject":"Re: [GSOC RFC PATCH] builtin/repo: add path.in-worktree field","fromName":"Lucas Seiki Oshiro","fromEmail":"lucasseikioshiro@gmail.com","sentAt":"2026-02-25T19:37:05Z","receivedAt":"2026-02-25T19:37:21Z","isPatch":true,"sender":{"key":"lucasseikioshiro@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12701580?v=4"},"body":"\n\n> Hi everyone,\n\nHi!\n\n> In this patch I am trying to provide the equivalent functionality of\n> 'git rev-parse --is-inside-work-tree'\n\nI'm not sure if it should be in git-repo-info. I mean, this information\nis more related to the current directory than the repository itself.\n\n> I found that I could either use the 'is_inside_work_tree' inside setup.h\n> which does not take anything , or use the 'is_inside_dir' from dir.h\n> and use the worktree directory in the repo variable that the function\n> is getting. \n> I went with the latter because the former was using 'the_repository'\n> inside.\n\nMakes sense, but this way you're re-writing `is_inside_work_tree`\ninside `get_path_in_worktree` but without using the is_inside_work_tree\nvariable. I don't know what's the cost of doing this.\n\nSomething that I would question here if isn't it possible to make\nis_inside_work_tree accept a repository as parameter and then use it\nhere.\n\n> Although I am not sure if 'path.in-worktree' is the best name for it.\n\nI think 'path.is-in-worktree' would be better.\n\n> Also, I did run t1900-repo.sh and it was failing one test case,\n> which also ran with an ok when I added the new field to REPO_INFO_KEYS.\n> \n> [1] : https://git.github.io/SoC-2026-Ideas/\n\nEverything above is not meant to be a commit message. This way, it\nshould be placed after the scissors mark (---) or in a cover letter.\n\n> +static int get_path_in_worktree(struct repository *repo, struct strbuf *buf)\n> +{\n> + strbuf_addstr(buf, is_inside_dir(repo->worktree) ? \"true\" : \"false\");\n> + return 0;\n> +}\n> +\n> /* repo_info_fields keys must be in lexicographical order */\n> static const struct field repo_info_fields[] = {\n> { \"layout.bare\", get_layout_bare },\n> { \"layout.shallow\", get_layout_shallow },\n> { \"object.format\", get_object_format },\n> + { \"path.in-worktree\", get_path_in_worktree },\n> { \"references.format\", get_references_format },\n> };\n\nOk, the process of adding a new field to repo-info is correct.\n\n> diff --git a/t/t1900-repo.sh b/t/t1900-repo.sh\n> index 51d55f11a5..d793d1b8e2 100755\n> --- a/t/t1900-repo.sh\n> +++ b/t/t1900-repo.sh\n> @@ -10,6 +10,7 @@ REPO_INFO_KEYS='\n> layout.bare\n> layout.shallow\n> object.format\n> + path.in-worktree\n> references.format\n> '\n\nTest missing here.\n\nThanks for your interest in contributing to git-repo-info!\n\n"},{"id":"537223","messageId":"20260226201643.5152-1-valusoutrik@gmail.com","threadId":"65076","inReplyTo":"05C28DD8-251A-4990-BBB2-26C144CAD982@gmail.com","subject":"Re: [GSOC RFC PATCH] builtin/repo: add path.in-worktree field","fromName":"SoutrikDas","fromEmail":"valusoutrik@gmail.com","sentAt":"2026-02-26T20:16:43Z","receivedAt":"2026-02-26T20:17:06Z","isPatch":true,"sender":{"key":"valusoutrik@gmail.com","avatar":"https://avatars.githubusercontent.com/u/56778179?v=4"},"body":"> Makes sense, but this way you're re-writing `is_inside_work_tree`\n> inside `get_path_in_worktree` but without using the is_inside_work_tree\n> variable. I don't know what's the cost of doing this.\n\nI also dont know for sure, but the is_inside_work_tree in setup.c has a\nlazy cache ie a 'static int inside_work_tree' ... but this lazy cache\nas far as I understood, does not survive after a command run. \n\n\n> I'm not sure if it should be in git-repo-info. I mean, this information\n> is more related to the current directory than the repository itself.\n\nI see. Very well, I was searching for something small enough to count\nas a microproject. If I may ask, can you give some directions ?\nI though about doing the group key thing : \n\n> Use the category as key (e.g., git repo info layout would return all \n> layout-related values)\n\nBut its already on the SoC 2026 Ideas , and I dont know if I should do\nit.\n\n\n> Something that I would question here if isn't it possible to make\n> is_inside_work_tree accept a repository as parameter and then use it\n> here.\n\nLike change the function in setup.c ? wouldnt that break every call of \nis_inside_work_tree ? Or make a similar function , along with a lazy cache\njust for repo.c ? \n\n> I think 'path.is-in-worktree' would be better.\n\nGot it.\n\n> Also, I did run t1900-repo.sh and it was failing one test case,\n> which also ran with an ok when I added the new field to REPO_INFO_KEYS.\n> \n> [1] : https://git.github.io/SoC-2026-Ideas/\n\n> Everything above is not meant to be a commit message. This way, it\n> should be placed after the scissors mark (---) or in a cover letter.\n\nGot it.\n\n\n> Test missing here.\n\nYeah ... I missed that. Suppose we were adding this path.is-in-worktree\nto repo.c , then would the below test be sufficient ? \n1: cd .git and then checking if path.is-in-worktree is false \n2: cd .. and then checking if path.is-in-worktree is true\n\n> Thanks for your interest in contributing to git-repo-info!\n\nThank you for the feedback and all the encouragement in the other thread\nas well.\n"},{"id":"537247","messageId":"BEE3B56B-F8E0-43B5-95EA-8506A84CB2EA@gmail.com","threadId":"65076","inReplyTo":"20260226201643.5152-1-valusoutrik@gmail.com","subject":"Re: [GSOC RFC PATCH] builtin/repo: add path.in-worktree field","fromName":"Lucas Seiki Oshiro","fromEmail":"lucasseikioshiro@gmail.com","sentAt":"2026-02-26T21:26:41Z","receivedAt":"2026-02-26T21:26:57Z","isPatch":true,"sender":{"key":"lucasseikioshiro@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12701580?v=4"},"body":"\n> I see. Very well, I was searching for something small enough to count\n> as a microproject. If I may ask, can you give some directions ?\n\nI don't think this is small enough to count as a microproject. A\nmicroproject is something simpler than that. See the microprojects\npage [1] for suggestions. They are more straightforward things that\nhave more chances of being accepted quickly. And since having an accepted\nmicroproject is a mandatory step, you'll probably want it to be merged\nas soon as possible.\n\n> I though about doing the group key thing : \n> \n>> Use the category as key (e.g., git repo info layout would return all \n>> layout-related values)\n> \n> But its already on the SoC 2026 Ideas , and I dont know if I should do\n> it.\n\nI think that this seems to be easy to do, but the reviewing process\nmay take some time, so it would be better if you stick to a\none of the selected microprojects [1].\n\n>> Something that I would question here if isn't it possible to make\n>> is_inside_work_tree accept a repository as parameter and then use it\n>> here.\n> \n> Like change the function in setup.c ? wouldnt that break every call of \n> is_inside_work_tree ?\n\nYeah, but then we would need to change all the calls to it, using\nthe_repository at first. But I really don't know, I'll leave this\ndiscussion for more experienced people.\n\n> Yeah ... I missed that. Suppose we were adding this path.is-in-worktree\n> to repo.c , then would the below test be sufficient ? \n> 1: cd .git and then checking if path.is-in-worktree is false \n> 2: cd .. and then checking if path.is-in-worktree is true\n\nYou can take a look on how `git rev-parse --is-inside-work-tree` is\nbeing tested today and use it as a base, since\n`git repo info path.is-inside-work-tree` would return true or false\nin the same situations.\n\n[1] https://git.github.io/SoC-2024-Microprojects/\n"},{"id":"537252","messageId":"xmqqtsv3uoc4.fsf@gitster.g","threadId":"65076","inReplyTo":"BEE3B56B-F8E0-43B5-95EA-8506A84CB2EA@gmail.com","subject":"Re: [GSOC RFC PATCH] builtin/repo: add path.in-worktree field","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-02-26T22:33:47Z","receivedAt":"2026-02-26T22:33:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> writes:\n\n> A\n> microproject is something simpler than that. See the microprojects\n> page [1] for suggestions. They are more straightforward things that\n> have more chances of being accepted quickly. And since having an accepted\n> microproject is a mandatory step, you'll probably want it to be merged\n> as soon as possible.\n\nMicroproject is to serve as a practice session for a new contributor\nto go through the patch submission + getting reviewed + sending\npolished version cycle.  It does not have to result in a merge to\nthe project, but it is essential to get reviewed and respond to\nreviews.  How well you work with reviewers is the focus of the\nobservation, and how complex the problem you tackle is is of much\nlessor importance.\n\n> I think that this seems to be easy to do, but the reviewing process\n> may take some time, so it would be better if you stick to a\n> one of the selected microprojects [1].\n>\n> [1] https://git.github.io/SoC-2024-Microprojects/\n\nIs https://git.github.io/SoC-2026-Microprojects/ the latest?  The\nabove URL points at one a few years old.\n\nAnyway, this list however might want a bit of updating.\n\n * I personally feel that \"run_command*() to internal call\" is way\n   too involved for a microproject.  All the low-hanging frutis have\n   already been picked in this area, I think.  That is why this does\n   not appear in the list of microproject ideas in more recent\n   years.\n\n * People seem to be finding more instances of \"test -X\" to replace\n   with test_path_is_* helpers, so that would be fine to keep for\n   now.\n\n * Ditto for \"do not place git upstream of a pipe\".\n\n * \"Do not use signed int for collection of flag bits\" may have\n   outlived its usefulness, as it seems we are pushing more and more\n   uses of enum for collection of flag bits.\n\n"},{"id":"537253","messageId":"AC839D5A-0221-4935-9E9B-92C2BB612C60@gmail.com","threadId":"65076","inReplyTo":"xmqqtsv3uoc4.fsf@gitster.g","subject":"Re: [GSOC RFC PATCH] builtin/repo: add path.in-worktree field","fromName":"Lucas Seiki Oshiro","fromEmail":"lucasseikioshiro@gmail.com","sentAt":"2026-02-26T22:38:46Z","receivedAt":"2026-02-26T22:39:02Z","isPatch":true,"sender":{"key":"lucasseikioshiro@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12701580?v=4"},"body":"\n> Microproject is to serve as a practice session for a new contributor\n> to go through the patch submission + getting reviewed + sending\n> polished version cycle.  It does not have to result in a merge to\n> the project, but it is essential to get reviewed and respond to\n> reviews.  How well you work with reviewers is the focus of the\n> observation, and how complex the problem you tackle is is of much\n> lessor importance.\n> \n>> I think that this seems to be easy to do, but the reviewing process\n>> may take some time, so it would be better if you stick to a\n>> one of the selected microprojects [1].\n>> \n>> [1] https://git.github.io/SoC-2024-Microprojects/\n> \n> Is https://git.github.io/SoC-2026-Microprojects/ the latest?  The\n> above URL points at one a few years old.\n\nOops. I've trusted by browser history and pasted the link that I\nduring my application.\n\nThanks for correcting me.\n"},{"id":"537267","messageId":"20260227035122.5588-1-valusoutrik@gmail.com","threadId":"65076","inReplyTo":"BEE3B56B-F8E0-43B5-95EA-8506A84CB2EA@gmail.com","subject":"Re: [GSOC RFC PATCH] builtin/repo: add path.in-worktree field","fromName":"SoutrikDas","fromEmail":"valusoutrik@gmail.com","sentAt":"2026-02-27T03:51:22Z","receivedAt":"2026-02-27T03:51:34Z","isPatch":true,"sender":{"key":"valusoutrik@gmail.com","avatar":"https://avatars.githubusercontent.com/u/56778179?v=4"},"body":"> I don't think this is small enough to count as a microproject. A\n> microproject is something simpler than that. See the microprojects\n> page [1] for suggestions. They are more straightforward things that\n> have more chances of being accepted quickly. And since having an accepted\n> microproject is a mandatory step, you'll probably want it to be merged\n> as soon as possible.\n\nMy bad, by microproject I meant this : \n\n> GSoc 2026 Idea : Improve the new git repo command\n>\n> Getting started: Build Git from source, experiment with git repo info \n> and git repo structure commands, study the implementation in builtin/repo.c,\n> review the initial GSoC proposal and discussions, compare functionality\n> with git rev-parse and identify gaps, and submit a *micro-patch to \n> demonstrate familiarity with the codebase*.\n\nI guess I misunderstood, I thought a relevant micropatch to the project\nidea area ( ie repo.c ) had to be submitted along with a general microproject.\n\nI did submit one code microproject [1] and a doc-fix [2]\n\n> I think that this seems to be easy to do, but the reviewing process\n> may take some time, so it would be better if you stick to a\n> one of the selected microprojects.\n\nNow since a microproject in the gsoc idea domain is not mandatory ... \nI think it would be okay to start on this ? \nRegardless of it being fully reviewed, I feel like I should do some work\non repo.c before writing a gsoc proposal. That way I can better formulate\na timeline, maybe.\n\n> Yeah, but then we would need to change all the calls to it, using\n> the_repository at first. But I really don't know, I'll leave this\n> discussion for more experienced people.\n\nAlright.\n\n> You can take a look on how `git rev-parse --is-inside-work-tree` is\n> being tested today and use it as a base, since\n> `git repo info path.is-inside-work-tree` would return true or false\n> in the same situations.\n\nRight, I dont know why I didn't do that, I will do that and send a patch v2\n\n[1] : 20260209172445.39536-1-valusoutrik@gmail.com\n[2] : pull.2187.git.git.1770293021383.gitgitgadget@gmail.com\n"},{"id":"537568","messageId":"96d93ef3-7843-4be7-925e-202888670373@gmail.com","threadId":"65076","inReplyTo":"xmqqtsv3uoc4.fsf@gitster.g","subject":"Re: [GSOC RFC PATCH] builtin/repo: add path.in-worktree field","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2026-03-02T18:08:10Z","receivedAt":"2026-03-02T18:08:17Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Hi Junio,\n\nOn 27/02/26 04:03, Junio C Hamano wrote:\n> Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> writes:\n> Is https://git.github.io/SoC-2026-Microprojects/ the latest?  The\n> above URL points at one a few years old.\n> \n> Anyway, this list however might want a bit of updating.\n> \n>   * I personally feel that \"run_command*() to internal call\" is way\n>     too involved for a microproject.  All the low-hanging frutis have\n>     already been picked in this area, I think.  That is why this does\n>     not appear in the list of microproject ideas in more recent\n>     years.\n> \n>   * People seem to be finding more instances of \"test -X\" to replace\n>     with test_path_is_* helpers, so that would be fine to keep for\n>     now.\n> \n>   * Ditto for \"do not place git upstream of a pipe\".\n> \n>   * \"Do not use signed int for collection of flag bits\" may have\n>     outlived its usefulness, as it seems we are pushing more and more\n>     uses of enum for collection of flag bits.\n> \n\nThank you for your suggestions. We've tried to tweak the micro-project\npage to remove the stale ones.\n\n   https://git.github.io/SoC-2026-Microprojects/\n\nFeel free to let us know if you have any further suggestions.\n\n--\nSivaraam\n\n"}]}