All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Scott R Parish <srp@srparish.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 6/7] walk PATH to generate list of commands for "help -a"
Date: Wed, 24 Oct 2007 21:42:42 -0700	[thread overview]
Message-ID: <7vve8v24al.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 1193283437-1706-6-git-send-email-srp@srparish.net

Scott R Parish <srp@srparish.net> writes:

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

Rationale?

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.

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

  parent reply	other threads:[~2007-10-25  4:43 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           ` Junio C Hamano [this message]
2007-10-25  5:07             ` [PATCH 6/7] walk PATH to generate list of commands for "help -a" Scott Parish
2007-10-25  5:33               ` Junio C Hamano
2007-10-25  7:07                 ` Scott Parish
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=7vve8v24al.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=srp@srparish.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.