Can GIT_EXEC_PATH behave more like PATH?

Can GIT_EXEC_PATH behave more like PATH?

[Martin Atukunda]

Hi,

I've been wondering if GIT_EXEC_PATH shouldn't be able to behave more
like the PATH env. variable?

it would allow for instance something like:

GIT_EXEC_PATH=/git/core:/usr/local/git/potty:/usr/lib/git

and naturally git <command> would do the correct thing given.

if so, definetly post 1.0 stuff.

any ideas?

- Martin -

-- 
Due to a shortage of devoted followers, the production of great leaders has been discontinued.

Re: Can GIT_EXEC_PATH behave more like PATH?

[Junio C Hamano]

Martin Atukunda <matlads@dsmagic.com> writes:

> I've been wondering if GIT_EXEC_PATH shouldn't be able to behave more
> like the PATH env. variable?

I do not think it is useful at all.

I think GIT_EXEC_PATH is useful only in two occasions.  (1) When
Porcelains want to bypass "git" to avoid extra forking, it can
ask where the executables are just once to "git --exec-path",
and export GIT_EXEC_PATH with that single path; (2) When you
want to try out a freshly built git without installing, you can
export GIT_EXEC_PATH set, again with the single path that is
where the build directory is.  Neither wants a list of
directories.

When users use "git frotz", the git command internally knows
where the right version of subcommands are stored.  When reason
you would want to override that, you would exactly know one
directory with which you want to override it.  You do not want
GIT_EXEC_PATH="/usr/lib/git-1.02:/usr/lib/git" in such a case,
either.

Re: Can GIT_EXEC_PATH behave more like PATH?

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> When users use "git frotz", the git command internally knows
> where the right version of subcommands are stored.  When reason
> you would want to override that, you would exactly know one
> directory with which you want to override it.  You do not want
> GIT_EXEC_PATH="/usr/lib/git-1.02:/usr/lib/git" in such a case,
> either.

OOPS.  That did not parse so well.  "... When you would want to
override that for whatever reason, you would..."