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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mar 20, 2011, 08:20 UTC
Message-ID: <20110320082020.GA12663@elie>
In-Reply-To: <7voc56rj9f.fsf@alter.siamese.dyndns.org>

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.