Re: Git fails to detect subcommand when hook is symlinked to a builtin

[Jonathan Nieder <jrnieder@gmail.com>]

Junio C Hamano wrote:

> Ok, that explains it.  update-server-info wasn't a built-in, so didn't
> have to look at its name to decide what to do.  It didn't have to spawn
> other git commands from GIT_EXEC_PATH so running the command directly
> without setting the environment variable happened to work.

Nice detective work.

> But such a usage (this doesn't have anything to do with the symlinking)
> was deprecated way before 1.5.4 [*1*], so the answer is still "don't do
> that" ;-)
[...]
> *1* http://thread.gmane.org/gmane.comp.version-control.git/93511

After rereading some of that thread (oops), I feel a small clarification
is in order.  Yes, the dashed named git-update-server-info is not the
name that that command would preferred to be called by, but if I
understand correctly, this is not what you are talking about having
being deprecated and removed.  Instead, the rule is:

 If you set your $PATH to include $(git --exec-path), then you may still
 run traditional git-<command>s using that dashed name.  Otherwise, you
 may be lucky and find it working (which is probably a bug :)) but
 please, just say no.[1]

Rationale: in that thread, the change to $PATH was agreed on as a
long-term workaround for preserving scripts and muscle memory.

Regards,
Jonathan

[1] In practice: the git wrapper adds GIT_EXEC_PATH to the $PATH and
traditional commands rely on finding it there.  For example, when
git-<command> is a shell script, it will tend to begin by reading in
some useful functions by running ". git-sh-setup", which relies on
git-sh-setup lying on the $PATH.