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
