From: Kousik Sanagavarapu <five231003@gmail.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [Question] local paths when USE_THE_REPOSITORY_VARIABLE is not defined
Date: Wed, 9 Oct 2024 11:50:08 +0530 [thread overview]
Message-ID: <ZwYgmNe6qk6jBZVT@five231003> (raw)
In-Reply-To: <ZwX7ieAvmjQma45E@pks.im>
On Wed, Oct 09, 2024 at 05:42:01AM +0200, Patrick Steinhardt wrote:
> On Tue, Oct 08, 2024 at 11:29:51PM +0530, Kousik Sanagavarapu wrote:
> > On Tue, Oct 08, 2024 at 02:23:54PM +0200, Patrick Steinhardt wrote:
> > > On Mon, Oct 07, 2024 at 10:24:49PM +0530, Kousik Sanagavarapu wrote:
> > > > Hi,
> > > >
> > > > I have two questions but a bit of a background first -
> > > >
> > > > [...]
> > > >
> > > > So my question is - do we want, in the future in which we are free from
> > > > the dependency on "the_repository", for all the local paths to be a part
> > > > of "struct repo_path_cache"? Which in my gut feels wrong - one alternative
> > > > then is that we will have to refactor REPO_GIT_PATH_FUNC - or am I missing
> > > > something here?
> > >
> > > What I don't quite understand: what is the problem with making it part
> > > of the `struct repo_path_cache`? Does this cause an actual issue, or is
> > > it merely that you feel it is unnecessary complexity?
> >
> > I feel it is unnecessary complexity.
> >
> > $ git grep -E "(static GIT_PATH_FUNC|^GIT_PATH_FUNC)" | wc -l
> > 65
> >
> > Meaning each of these would have to have an entry in
> > "struct repo_path_cache" in the world where we don't rely on
> > "the_repository". Some of these are also not direct ".git/some-file" but
> > ".git/dir/files" where ".git/dir" is also given by a seperate path func,
> > like ".git/rebase-merges" and ".git/rebase-merges/head-name".
> >
> > So why hold pointers to such filenames instead of just calling
> > repo_git_path() manually - all these filenames are "local" anyways - unlike
> > say files such as "SQUASH_MSG"?
>
> It does make the interface easier to use at times because you don't have
> to worry about freeing returned strings. In other situations it likely
> is unnecessary.
>
> In any case, not all cases must strictly be converted to REPO_PATH_FUNC.
> A refactoring may also decide that using e.g. `repo_git_path()` or
> `repo_common_pathv()` might be better alternatives.
Got it. Thanks again for the nice explanations.
prev parent reply other threads:[~2024-10-09 6:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-07 16:54 [Question] local paths when USE_THE_REPOSITORY_VARIABLE is not defined Kousik Sanagavarapu
2024-10-08 12:23 ` Patrick Steinhardt
2024-10-08 17:59 ` Kousik Sanagavarapu
2024-10-09 3:42 ` Patrick Steinhardt
2024-10-09 6:20 ` Kousik Sanagavarapu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZwYgmNe6qk6jBZVT@five231003 \
--to=five231003@gmail.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).