From: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
Date: Fri, 04 Sep 2026 14:37:06 GMT
Subject: Re: [GSoC Patch v5 7/7] repo: add path.cdup
Message-ID: <CA+rGoLcZ6u+Rbz2PNGiaPbeHB=LSAqxi0r6jYZL3RjG6wimJ3Q@mail.gmail.com>
In-Reply-To: <xmqq7blem1y6.fsf@gitster.g>

Hey Junio,

On Wed, Aug 26, 2026 at 1:01 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:
>
> > +static int get_path_cdup(struct repository *repo, struct strbuf *buf)
> > +{
> > +     const char *pfx = repo->prefix;
> > +
> > +     while (pfx) {
> > +             pfx = strchr(pfx, '/');
> > +             if (pfx) {
> > +                     pfx++;
> > +                     strbuf_addstr(buf, "../");
> > +             }
> > +     }
> > +     return 0;
> > +}
>
> Can we have a small common helper library (e.g., repo-info.c at the
> top level) shared between this code and builtin/rev-parse.c so
> that we have only a single implementation of 'cdup'?
>
> The same comment applies to all the other features that duplicate
> implementations from rev-parse and elsewhere in the repo-info file.

Apologies for the late response, I had a hectic exam week : )

I started working on this, but I wanted to check how to
structure the commits cleanly.

Would it be okay to queue this `path.*` series as-is first, and
then address the deduplication in a follow-up refactoring series
right after (provided there are no other concerns)?

Grouping the new `git repo info` keys with the cleanup of
`git rev-parse` in a single series would mix feature additions with
legacy refactoring. Additionally, since earlier path keys are
already merged, moving the shared library to a follow-up series
keeps both topics clear.

In that follow-up set, I can introduce the library alongside porting
the first command to use it, and then port the remaining overlapping
commands one by one in subsequent commits so each patch remains a
self-contained, bisectable change.

Please let me know if this works for you!

Regards,
- K Jayatheerth