I noticed a typo I made. I meant `git-config` rather than
`git-commit`. Sorry for my mistake.
On Mon, Feb 11, 2013 at 12:57 AM, Ethan Reesor <firelizz...@gmail.com> wrote:
> 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
> 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
>> 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
Ethan Reesor (Gmail)
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