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 <firelizzard@xxxxxxxxx> wrote: > On Mon, Feb 11, 2013 at 12:22 AM, Junio C Hamano <gitster@xxxxxxxxx> 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 > [shell] > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html