Re: [PATCH 6/7] walk PATH to generate list of commands for "help -a"

From: Scott Parish <srp@srparish.net>
Date: Oct 25, 2007, 05:07 UTC
Message-ID: <20071025050736.GG759@srparish.net>
In-Reply-To: <7vve8v24al.fsf@gitster.siamese.dyndns.org>

On Wed, Oct 24, 2007 at 09:42:42PM -0700, Junio C Hamano wrote:

Show 5 quoted lines

> Scott R Parish <srp@srparish.net> writes:
> 
> > Signed-off-by: Scott R Parish <srp@srparish.net>
> 
> Rationale?

Well, the ultimate reason that i've been working on all of this is i'd like to push git as a viable development tool where i work. To give an effective idea, lets say that shared tools get placed on nfs servers, which can be mounted to different paths depending on which nfs server is up or down or which system is the nfs client.

I have no control over each users PATH nor things like MANPATH or GIT_EXEC_PATH and have no way of compiling in a path ahead of time, but i would like to provide the easiest user experiance possible, meaning that whether they have git in their PATH, or whether they are using an absolute or relative path to it, it just works, hopefully including "git help" and "git help -a".

Should i be putting all that in my commit messages?

Show 8 quoted lines

> There are two cases execv_git_cmd() runs "git-that" from a non
> standard place, if we take your [PATCH 4/7].
> 
>  - If there is a directory that contains a location that used to
>    hold an old installation of git-* commands (some of which may
>    have been removed in the latest git) and if the user has that
>    directory on PATH, we would run obsolete git subcommand from
>    there.

I could see that as being problematic. I suppose there are ways around that (have "git" pass to "git-cmd" an argument of what version it is) but none that i really like.

Show 11 quoted lines

>  - If the user has a custom command "git-that" in $HOME/bin/
>    that is outside GIT_EXEC_PATH, the new subcommand "that" can
>    be used as if it is part of the official git.  This is an
>    improvement [PATCH 4/7] would bring in.  We allow this
>    already for scripts anyway, and the patch is merely making
>    the behaviour of the execv_git_cmd() consistent with it.
> 
> It may be nicer if the user can somehow tell from the output if
> each of the command is from the standard set (i.e. on
> GIT_EXEC_PATH or built-in), or from a non standard place (either
> custom command as intended, or an unintended obsolete leftover).

What if git marked commands that weren't found in the location where it thinks that it is running from?

sRp

-- 
Scott Parish
http://srparish.net/