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

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. A trace may help illustrate:

With hooks/post-update as a symlink to /usr/bin/git-update-server-info:

trace: run_command: 'hooks/post-update' 'refs/heads/master' trace: run_command: 'gc' '--auto' '--quiet' remote: trace: exec: 'git-refs/heads/master' remote: trace: run_command: 'git-refs/heads/master' remote: git: 'refs/heads/master' is not a git command. See 'git --help'.

With hooks/post-update as a symlink to /usr/share/git-core/templates/hooks/post-update.sample:

trace: run_command: 'hooks/post-update' 'refs/heads/master' remote: setup: git_dir: . remote: setup: worktree: (null) remote: setup: cwd: /home/fedora/tmz/tmp/iwhd.git remote: setup: prefix: (null) remote: trace: built-in: git 'update-server-info'

Is there any reasonable way to handle this case? Perhaps if the symlink were dereferenced (if no subcommand were found) and then re-checked for a subcommand? I admit that I did not delve too deeply into the code, but from the little I did I wasn't sure that any changes here wouldn't lead to worse troubles.