From: Scott Parish <sRp@srparish.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 6/7] walk PATH to generate list of commands for "help -a"
Date: Thu, 25 Oct 2007 00:07:45 -0700 [thread overview]
Message-ID: <20071025070744.GH759@srparish.net> (raw)
In-Reply-To: <7vk5pb21xv.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 24, 2007 at 10:33:32PM -0700, Junio C Hamano wrote:
> > 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.
Well, the exact details are completely fictitious, made up to
illustrate the situation without breaking confidential agreements.
I'm not sure i completely agree with the design, but there are good
reasons for it, and at this point i have little or no control over
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?
>
> 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
Nice! I'll try doing that, probably won't have time to finish until
later tomorrow.
sRp
--
Scott Parish
http://srparish.net/
next prev parent reply other threads:[~2007-10-25 7:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-25 3:37 [PATCH 1/7] "git" calls help_unknown_cmd(""); "git help" and "git help -a" return 0 Scott R Parish
2007-10-25 3:37 ` [PATCH 2/7] s/pattern/prefix/ in help's list_commands Scott R Parish
2007-10-25 3:37 ` [PATCH 3/7] "current_exec_path" is a misleading name, use "argv_exec_path" Signed-off-by: Scott R Parish <srp@srparish.net> Scott R Parish
2007-10-25 3:37 ` [PATCH 4/7] use only the PATH for exec'ing git commands Scott R Parish
2007-10-25 3:37 ` [PATCH 5/7] chdir() into list_commands() dir instead of building paths for stat() Scott R Parish
2007-10-25 3:37 ` [PATCH 6/7] walk PATH to generate list of commands for "help -a" Scott R Parish
2007-10-25 3:37 ` [PATCH 7/7] shell should call setup_path() instead of manually setting up its path Scott R Parish
2007-10-25 4:42 ` [PATCH 6/7] walk PATH to generate list of commands for "help -a" Junio C Hamano
2007-10-25 5:07 ` Scott Parish
2007-10-25 5:33 ` Junio C Hamano
2007-10-25 7:07 ` Scott Parish [this message]
2007-10-25 4:41 ` [PATCH 2/7] s/pattern/prefix/ in help's list_commands Junio C Hamano
2007-10-25 4:53 ` Scott Parish
2007-10-25 6:30 ` [PATCH 2/7] remove unused/unneeded "pattern" argument of list_commands Scott R Parish
2007-10-25 6:32 ` [PATCH 5/7] chdir() into list_commands() dir instead of building paths for stat() Scott R Parish
2007-10-25 4:40 ` [PATCH 1/7] "git" calls help_unknown_cmd(""); "git help" and "git help -a" return 0 Junio C Hamano
2007-10-25 4:52 ` Scott Parish
2007-10-26 23:03 ` Junio C Hamano
2007-10-27 7:16 ` Scott Parish
-- strict thread matches above, loose matches on Subject: below --
2007-10-27 8:36 [PATCH 1/7] "git" returns 1; " Scott R Parish
2007-10-27 8:36 ` [PATCH 2/7] remove unused/unneeded "pattern" argument of list_commands Scott R Parish
2007-10-27 8:36 ` [PATCH 3/7] "current_exec_path" is a misleading name, use "argv_exec_path" Scott R Parish
2007-10-27 8:36 ` [PATCH 4/7] list_commands(): simplify code by using chdir() Scott R Parish
2007-10-27 8:36 ` [PATCH 5/7] use only the $PATH for exec'ing git commands Scott R Parish
2007-10-27 8:36 ` [PATCH 6/7] walk $PATH to generate list of commands for "help -a" Scott R Parish
2007-10-28 6:18 ` Junio C Hamano
2007-10-28 9:45 ` Scott Parish
2007-10-28 10:07 ` Junio C Hamano
2007-10-28 11:15 ` Scott Parish
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071025070744.GH759@srparish.net \
--to=srp@srparish.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).