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