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
presenting a
git>
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.
Jonathan
--
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
