Junio C Hamano wrote:
> The purpose of the directory is to keep custom commands that are
> allowed. If the site administrator does not want any command, it
> would be more natural to expect that the way to disable them would
> be _not_ to have that directory which is a collection of allowed
> commands. Adding that directory and add a "help" that exits with
> non-zero feels quite a roundabout and counter-intuitive way, no?
I think it comes down to the reason the site admin doesn't want to
allow interactive logins. That reason seems to be mostly that
prompt at which you can only ask for "help" or "exit" is a bit
confusing and pointless. I have sympathy for that, which is why I
looked for a way for the admin to ask to avoid the prompt altogether
in that case.
I do not think the reason is "because I don't want a
git-shell-commands directory". I think it's good to have basically
one kind of setup instead of significantly different ones with and
without that special directory --- and it means that starting from a
setup like this, one can easily drop in additional commands like
set-head or create-repo without changing anything basic. It's making
the admin's later life easier.
Maybe a better test than "help exits with special exit code" is "there
are no other custom commands than help". Would that be more sensible?
>From a "make it possible to emulate gitolite" point of view, that
doesn't permit disabling the interactive mode when there are other
commands available, so my hunch is that it wouldn't.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html