From: Junio C Hamano Date: Sat, 19 Mar 2011 00:53:51 GMT Subject: Re: Git fails to detect subcommand when hook is symlinked to a builtin Message-ID: <7vhbb0rkv4.fsf@alter.siamese.dyndns.org> In-Reply-To: <20110318151415.GC26236@inocybe.localdomain> Todd Zullinger writes: > I'm not sure if this is a bug or more of a "don't do that" sort of > thing. At fedorahosted.org, the git repositories are mounted on a > filesystem with noexec. As such, we have all hooks symlinked > elsewhere. For the post-update hook we used to link directly to > git-update-server-info. > > This worked until we upgraded the system to git-1.7.4.1 recently. I have a suspicion that we may end up saying "don't do that", but let's ponder a bit with some technical background first. The "git" wrapper and builtin commands are all the same binary, and as a consequence, their main() function needs to decide what to do based on argv[0]. If argv[0] is "git", we know argv[1] is the name of the subcommand, and if argv[0] is "git-foo", it might be the internal call from the "git" wrapper that was invoked with argv[] = { "git", "foo", ... }, but we don't expect that argv[0] to be things like "post-update". But it is curious why the resulting behaviour changed recently. The symptom hints that the link target (git-update-server-info in your case) used to be given as argv[0] (which still wouldn't have been kosher---you are not supposed to use dashed form since 1.5.4 or so without adding $GIT_EXEC_PATH at the beginning of your $PATH, and that is why I said the first sentence in this reply), but we recently changed something and now we are getting "hooks/post-update" in argv[0]. I suspect the recent change to run hooks via run_command() interface has something to do with it. From what version did you update to 1.7.4.1?