Todd Zullinger <tmz@xxxxxxxxx> 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?
--
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