Re: [GSoC][PROPOSAL] Improve the new git repo command

From: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
Date: Mar 17, 2026, 14:47 UTC
Message-ID: <CA+rGoLe70x2Ns5e8qHm3n-yvNxQbAc1b=Mqm31GDsMCOfJjNFw@mail.gmail.com>
In-Reply-To: <CAOLa=ZS6HtJrWd0kfsFASCbP2S9-MQq5Da3feA0WqY8ykZ0WTw@mail.gmail.com>

Hey Karthik,

Thank you for taking time to go through the proposal.

Show 20 quoted lines

> > * *Implementation:* I will implement an internal mapping
> >   structure so that calling `git repo info path`
> >   successfully identifies the category root and iterates
> >   through all keys starting with `path.*`, returning them
> >   dynamically.
> >
>
> This would definitely be nice to have. Have you also thought about glob
> pattern matching too? That way a user could do
>
>   $ git repo info "path*"
>
> And have it list all keys which start with path. Similar to how you plan
> to do category matching, but this can also do
>
>   $ git repo info "*object*"
>
> So any keys with object in it would match too. Either ways I'm just
> thinking out loud and not saying this is what you _should_ do.
>

I hadn't thought about globbing till now but I have now given it a thought, I personally believe we don't need globs (at least not now)

There are hardly 4 elements in the array `repo_info_field` as of now even if we add all the paths I think it will not go beyond 20 elements. And I think globbing is a problem we would have to debate after we get to >= 30 elements, globbing has its advantages, it gets insanely flexible but I don't believe it is a current problem. I could however add an RFC in the community bonding period.

Show 10 quoted lines

> >   and explicitly evaluate the passed
> >   `struct repository *repo` pointer.
> >   I will thread this context down the call chain without
> >   breaking existing external callers.
> >
>
> It would be nice to collate some of the efforts already made in this
> direction, I know its not as simple [1] as passing in the repo since
> `is_bare_repository()` has a lot of callees.
>

After posting this proposal I was tweaking around and found out repo->worktree It holding a `NULL` value is directly supposed to indicate it is `bare` if I am correct?

I maybe wrong here But writing up a quick change where

static int get_layout_bare(struct repository *repo UNUSED, struct strbuf *buf) { strbuf_addstr(buf, is_bare_repository() ? "true" : "false"); return 0; }

becomes

static int get_layout_bare(struct repository *repo, struct strbuf *buf) { strbuf_addstr(buf, (repo->worktree == NULL) ? "true" : "false"); return 0; }

and removing the macro #define USE_THE_REPOSITORY_VARIABLE

would work is what I have dug so far I would of course not send a patch until GSoC starts But I wanted to know if I am thinking in the right direction here?

Show 8 quoted lines

> > * `path.git-dir`, `path.common-dir`, `path.worktree`.
> > * `path.objects`, `path.hooks`, `path.index`, and `path.grafts`.
> >
>
> This is the crux, but you should also probably involve some of the newer
> discussions around this. I added some pointers to Mansi's proposal, and
> perhaps that's something you should look into too. [2]
>

That's a great point I will update this.

Show 18 quoted lines

> > *Objective 4: Sparse Topology & Boundary Awareness* +
> > Modern Git workflows rely heavily on partial checkouts
> > and submodules, and `repo info` should report these
> > complex states natively.
> > * *Implementation:* I will implement `layout.is-sparse`
> >   to expose if the repository uses a sparse-checkout
> >   cone, and `path.superproject-working-tree` to instantly
> >   query if the current repository is a submodule.
> >
>
> Those may be good additions.
>
> > == 4. PROJECT TIMELINE
> >
> > === 4.1 Community Bonding Period (May 1 - May 24)
> >
> > * Attend the Git community GSoC sessions to introduce
> >   myself and establish a communication schedule.

Show 6 quoted lines

> >   resolution works correctly across POSIX and Windows
> >   environments.
>
> I think this will take way more time than the two weeks allocated here,
> mostly because of the design decisions we need finalize on.
>

I agree, I have actually changed a lot of my existing proposal I had a very hard time picking which project to leave out of scope since I like all the projects equally But I did double the allocated time in my existing proposal, I gave 4 weeks for paths and libification (Given that my above trail of thinking is correct it is just a small change i.e repo->worktree) I also gave 4 weeks for querying the prefixes

Gave a 3 weeks of buffer for path and libification and 2 weeks of buffer for query.

Show 14 quoted lines

> > *Weeks 10 - 12 (July 27 - August 16):*
> > * Implement the advanced topology and boundary keys
> >   (`layout.is-sparse` and `path.superproject-working-tree`).
> > * Run the full test suite and perform rigorous edge-case
> >   testing ensuring libification does not cause
> >   regressions.
> > * Buffer period for addressing mailing list feedback
> >   regarding the libification and sparse patches.
> >
>
> Overall I think this is trying to do many things in a short time frame.
> I would also consider the time it takes for reviews and iterations to
> land.
>

I just wanted to say that the proposal I posted is in a new thread I understand making it inline is nice But since a lot has changed I thought of adding it in a new thread to justify it [1]

Regards,
- Jayatheerth

1 - https://lore.kernel.org/git/CA+rGoLd4ho5AmB3gWYP=yUUKJO=YqthxKX8R_rvN7V7exArn6Q@mail.gmail.com/T/#u