intended use of "git --exec-path"?

"git --exec-path" presently prints out the highest priority path to find executable in. That's a what; i'm curious why and when it should be used. Basically i'm wondering if its still useful, and what, if anything, it should be printing.

Thanks sRp

Scott Parish <sRp@srparish.net> wrote:

git-gui uses it. git-gui runs git-* by prefixing it with the exec path. It also scans the first line of the file if we are on Windows and the "executable" doesn't end in ".exe" so it can figure out what process to run it through.

So it really can't go away.

On Wed, Oct 24, 2007 at 12:38:19AM -0400, Shawn O. Pearce wrote:

So it sounds like it might be more helpful for git to return its PATH, so other programs can set their PATH or search for executables accordingly.

sRp

On 10/24/07, Scott Parish <sRp@srparish.net> wrote:

You don't necessarily want to be monkeying around with $PATH if you're trying to use a particular git installation (say, a build of next) instead of your "proper" install, which is in your $PATH; if you call /some/random/path/git-whatever, it should use the git tools in /some/random/path/, not in $PATH.

Dave.

Scott Parish wrote:

git supports having all its "helpers" in a separate path. Since there were performance concerns with having scripts call the git wrapper for every invocation of every git program, the --exec-path option was added when the wrapper was rewritten in C.

Unless it's a very tight loop that runs non-builtin programs, there's really no reason for scripts to use the git-whatever form of commands, but the ability to do so should probably be retained more or less forever. See 8e49d50388211a0f3e7286f6ee600bf7736f4814 for details.