Re: "git stash" is not known to git

David Kastrup [off-list ref] writes:

One has to use git-stash rather than "git stash".  Oversight?

This looks like an incorrect installation, with git-stash in your
$PATH, but not in the place git looks for its commands (I don't
remember the exact mechanism).

-- 
Matthieu

Matthieu Moy [off-list ref] writes:

David Kastrup [off-list ref] writes:

quoted

One has to use git-stash rather than "git stash".  Oversight?

This looks like an incorrect installation, with git-stash in your
$PATH, but not in the place git looks for its commands (I don't
remember the exact mechanism).

I don't think so: in git.c we have at lines 362ff

                { "show-branch", cmd_show_branch, RUN_SETUP },
                { "show", cmd_show, RUN_SETUP | USE_PAGER },
                { "stripspace", cmd_stripspace },
                { "symbolic-ref", cmd_symbolic_ref, RUN_SETUP },

So it really seems like stash is not known to git.c.  Of course, I
have no real clue about git.c's operation (or I'd have proferred a
patch) and not right now the time to look further.

-- 
David Kastrup

On Mon, Jul 30, 2007 at 11:44:31AM +0200, Matthieu Moy wrote:

quoted

One has to use git-stash rather than "git stash".  Oversight?

This looks like an incorrect installation, with git-stash in your
$PATH, but not in the place git looks for its commands (I don't
remember the exact mechanism).

On a related note, is it just me, or is the following comment and related code
in git.c (introduced by Linus in 231af832) totally bogus:

  /*
   * We search for git commands in the following order:
   *  - git_exec_path()
   *  - the path of the "git" command if we could find it
   *    in $0
   *  - the regular PATH.
   */

We never actually look in the regular PATH since we call execv_git_cmd
(although we do still munge the PATH, apparently so shell scripts can
use git-foo syntax; see 77cb17e9). This means you can't drop "git-foo"
into your PATH and have it work as "git foo".

What is the desired behavior?

-Peff

On Mon, Jul 30, 2007 at 11:57:00AM +0200, David Kastrup wrote:

quoted

This looks like an incorrect installation, with git-stash in your
$PATH, but not in the place git looks for its commands (I don't
remember the exact mechanism).

I don't think so: in git.c we have at lines 362ff

                { "show-branch", cmd_show_branch, RUN_SETUP },
                { "show", cmd_show, RUN_SETUP | USE_PAGER },
                { "stripspace", cmd_stripspace },
                { "symbolic-ref", cmd_symbolic_ref, RUN_SETUP },

So it really seems like stash is not known to git.c.  Of course, I
have no real clue about git.c's operation (or I'd have proferred a
patch) and not right now the time to look further.

That list is for builtins; git-stash is an external shell script. See
execv_git_cmd for the list of places where it is looking for git-stash.

Since I seem to recall you working some symlink magic with your
installation in a recent message, that might be related. Is it just
git-stash, or are other scripts failing (try "git status")?

-Peff

Jeff King [off-list ref] writes:

Since I seem to recall you working some symlink magic with your
installation in a recent message, that might be related. Is it just
git-stash, or are other scripts failing (try "git status")?

Hmpf.  On another system (git version 1.5.3.rc3.48.g0d59d) this works.
I don't have the system at hand right now where it doesn't.  So it
would be my guess that either I have not called the install-symlinks
target recently enough, or its implementation on that system has been
broken for some time.

I'll have to check this evening.

On the other hand, I am quite sure that while "git stash" did not
work, "git-stash" had no problem.

So something bogus in git's PATH lookup would definitely appear to be
going on: it should be hard to get the symlinks messed up badly enough
to have one work and not the other.

More this evening.

-- 
David Kastrup

On Mon, Jul 30, 2007 at 12:24:51PM +0200, David Kastrup wrote:

On the other hand, I am quite sure that while "git stash" did not
work, "git-stash" had no problem.

Right. git-stash is in your PATH, but not in git's exec path (which is
_not_ the same as PATH).

So something bogus in git's PATH lookup would definitely appear to be
going on: it should be hard to get the symlinks messed up badly enough
to have one work and not the other.

Git doesn't look for subcommands in the PATH.

-Peff

Jeff King [off-list ref] writes:

On Mon, Jul 30, 2007 at 12:24:51PM +0200, David Kastrup wrote:

quoted

On the other hand, I am quite sure that while "git stash" did not
work, "git-stash" had no problem.

Right. git-stash is in your PATH, but not in git's exec path (which is
_not_ the same as PATH).

How does it calculate its exec path?  It would appear that it would
not contain _either_ /usr/local/bin _or_ /opt/git/bin in my
installation if it can't find git-stash (which should be statable in
both places).

Have a command handy for checking the exec path?

Ok, this is pretty much idle speculation until I am back at the system
in question, but I have problems envisioning just what kind of goof
might have happened here.

-- 
David Kastrup

On Mon, Jul 30, 2007 at 12:52:40PM +0200, David Kastrup wrote:

How does it calculate its exec path?  It would appear that it would
not contain _either_ /usr/local/bin _or_ /opt/git/bin in my
installation if it can't find git-stash (which should be statable in
both places).

See exec_cmd.c:execv_git_cmd. It checks in order:
  1. --exec-path= on command line
  2. $GIT_EXEC_PATH from environment
  3. GIT_EXEC_PATH defined at compile-time (set by Makefile from
      $(gitexecdir), which is generally the same as $(bindir))

So it should have /opt/git/bin in your case, but it's possible since
that is a Makefile variable that you failed to recompile correctly after
changing its value.

Have a command handy for checking the exec path?

git --exec-path

-Peff