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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html