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

[Junio C Hamano <gitster@pobox.com>]

Scott Parish <sRp@srparish.net> writes:

> On Wed, Oct 24, 2007 at 09:42:42PM -0700, Junio C Hamano wrote:
>
>> 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.

It sounds to me that your nfs client systems might find what
people usually expect in /usr/local/bin not there but on
/mnt/random47/bin depending on the system, without a reasonable
system administration effort that places stable symlinks to give
end users a consistent view of the world regardless from which
client, which sounds insane.  I personally do not think we
should support lazy system administrators by making git unsafe.

But using PATH as a fallback is what we already do for scripts,
and that is good enough to deal with such an installation.

> Should i be putting all that in my commit messages?

Even in a well behaved installation, where everything is found
where they should be (iow, GIT_EXEC_PATH), this is needed
because 4/7 lets you run a custom "git that" command from PATH
and this 6/7 is to teach "help -a" about it.  I think at least
that much needs to be said in the commit message.

>> 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.

As I said, this is making git a bit less safe from unintended
leftover executables, but the scripts already work that way and
your 4/7 merely makes the C level in line with that behaviour.
I do not think it is too much of a problem anyway.

>> 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?

Currently "git help -a" says "available in $where" at the top.
Perhaps make a separate list that is listed as "available from
elsewhere" and show the ones that are on PATH but not masked by
the ones on GIT_EXEC_PATH?

    git commands available in '/home/junio/git-next/bin'
    ----------------------------------------------------
      add                 gui                 rebase--interactive
      add--interactive    hash-object         receive-pack
      ...

    git commands available from elsewhere on your $PATH
    ----------------------------------------------------
      frotz               nitfol