Scott Parish <sRp@xxxxxxxxxxxx> writes:
> On Wed, Oct 24, 2007 at 09:42:42PM -0700, Junio C Hamano wrote:
>
>> Scott R Parish <srp@xxxxxxxxxxxx> writes:
>>
>> > Signed-off-by: Scott R Parish <srp@xxxxxxxxxxxx>
>>
>> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
