git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jordi Vilar <git.kernel.org@jordi.vilar.cat>
To: git@vger.kernel.org
Subject: proposal for additional search path in config
Date: Tue, 1 Jun 2021 16:13:18 +0200	[thread overview]
Message-ID: <CAE-zgtYTutLZWO63QtqZJztMPqi9eHYQfFu6sda8YDf_bVeE3Q@mail.gmail.com> (raw)
In-Reply-To: <20210601113554.52585C06174A@lindbergh.monkeyblade.net>

Hi folks,

I would like to gather feedback about a feature I'm considering about.
Basically, I would like to propose a configuration setting with a path
(possibly relative to the working tree) to look for executables. In
that way, a local clone could setup additional tools/scripts private
for its work tree, maybe also under revision control.

For instance, we could have a setting like:
  git config core.extensions_path "./scripts"
so that whenever git has to resolve an external command also includes
that path in the search, resolving relative paths to the work tree, in
this case, the "/scripts" subdir.

A simple use case could be a custom tool integrated with git, but
local to the repository and thus versioned.

For instance, let's assume that we have some metadata required by a
custom build tool that is stored in commit comments or tags, so we
have a custom script git-project-metadata to handle it:
  git project-metadata query ...

Maybe the format for the metadata evolves, so the script must evolve
also. Having it integrated in this way would allow that each checkout
sees the correct script version, and that script is always invoked as
a regular git command, without having to tweak the environment
everytime.

It is not clear to me whether it's a good idea for this additional
path to have priority over the default search path, as in one hand it
could allow to override the default tools, but in the other hand this
may be a hole for bad things... For my, the conservative approach of
having this additional path as a fallback is ok, so that it only adds
more commands, but doesn't override commands.

Also, this setting could be set either globally or locally, and in
this case, in the conservative approach, the overloading rule is the
different to the normal one: the system search path in the environment
path variable has precedence over the global setting and this over the
local setting, but all apply.

Does it sound reasonable? Is there interest in such feature?

Thanks,

Jordi

       reply	other threads:[~2021-06-01 14:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210601113554.52585C06174A@lindbergh.monkeyblade.net>
2021-06-01 14:13 ` Jordi Vilar [this message]
2021-06-02 11:08   ` proposal for additional search path in config Johannes Schindelin
2021-06-02 17:36     ` Jordi Vilar
2021-06-03  2:45       ` Taylor Blau

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=CAE-zgtYTutLZWO63QtqZJztMPqi9eHYQfFu6sda8YDf_bVeE3Q@mail.gmail.com \
    --to=git.kernel.org@jordi.vilar.cat \
    --cc=git@vger.kernel.org \
    /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).