On Mon, Feb 11, 2013 at 12:22 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Hmph, if that is the case, wouldn't it be a better direction to give
> a better help for majority of the case where git-shell is used as
> the login shell to allow push and fetch but not for interactive
> access at all?
> The first step in that direction may be to give a better canned
> message, followed by a mechanism (perhaps a hook) that lets a
> message customized for the site's needs, no?  Why should a site
> administrator create an otherwise empty directory for each and every
> user and add an executable in there that shows an error message,
> only to improve the default message because it is not friendly
> enough?

Jonathan made the following comment on the thread I started that lead
to this RFC:
> You can disable interactive logins by removing the
> ~/git-shell-commands/ directory.  Unfortunately that doesn't let you
> customize the message.  Perhaps it would make sense to teach shell.c
> to look for a
>        [shell]
>                greeting = 'Hi %(username)! You've successfully authenticated, 
> but I do not provide interactive shell access.'
> setting in git's config file.

How is this for an alternative? Have shell.c look for
                missing_commands_directory = "Stuff is broke."
setting. If the setting is missing, then it prints the default message
(the current message). That way, there's a default setting, there can
be a system-wide message, there can be a user specific message, and
those messages can be set via `git-commit`.

Ethan Reesor
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

Reply via email to