On Mon, Feb 11, 2013 at 09:18:18AM -0800, Junio C Hamano wrote:
> That "shell-disabled" thing was to allow customizing the existing
> die() that triggers here:
> [...]
> so it is more like
>
> if ! test -d $HOME/git-shell-commands
> then
> if test -x /etc/git/shell-disab
Jeff King writes:
> On Sun, Feb 10, 2013 at 11:17:24PM -0800, Junio C Hamano wrote:
>
>> Jonathan Nieder writes:
>>
>> > Isn't that a criticism of the git-shell-commands facility in general?
>> > If it is common to have a lot of users with distinct home directories
>> > but all with git-shell a
Jonathan Nieder writes:
> 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
On Sun, Feb 10, 2013 at 11:17:24PM -0800, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > Isn't that a criticism of the git-shell-commands facility in general?
> > If it is common to have a lot of users with distinct home directories
> > but all with git-shell as their login shell, then th
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
> com
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>
>>> Isn't that a criticism of the git-shell-commands facility in general?
>>> If it is common to have a lot of users with distinct home directories
>>> but all with git-shell as their login shell, then the
>>> git-shell
Ethan Reesor writes:
> On Mon, Feb 11, 2013 at 2:22 AM, Junio C Hamano wrote:
>> Ethan Reesor writes:
>>> Again, would it not be more elegant and powerful to A) have the
>>> shell-disabled message/hook/etc specified by git-config on some level,
>>> be it /etc/gitconfig or ~/.gitconfig, and B) h
On Mon, Feb 11, 2013 at 2:22 AM, Junio C Hamano wrote:
> Ethan Reesor writes:
>> Again, would it not be more elegant and powerful to A) have the
>> shell-disabled message/hook/etc specified by git-config on some level,
>> be it /etc/gitconfig or ~/.gitconfig, and B) have Jonathan's patch
>> where
Ethan Reesor writes:
>> For those who _do_ want to give customized commands to their users,
>> they can already have "help" script to give a friendly message. It
>> just felt silly to force sites to create the directory only to
>> refuse an access to the "custom commands" feature, especially whe
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Isn't that a criticism of the git-shell-commands facility in general?
>> If it is common to have a lot of users with distinct home directories
>> but all with git-shell as their login shell, then the
>> git-shell-commands should not go in their h
On Mon, Feb 11, 2013 at 2:12 AM, Jonathan Nieder wrote:
> Isn't that a criticism of the git-shell-commands facility in general?
> If it is common to have a lot of users with distinct home directories
> but all with git-shell as their login shell, then the
> git-shell-commands should not go in thei
Jonathan Nieder writes:
> Isn't that a criticism of the git-shell-commands facility in general?
> If it is common to have a lot of users with distinct home directories
> but all with git-shell as their login shell, then the
> git-shell-commands should not go in their home directory to begin
> wit
On Mon, Feb 11, 2013 at 2:01 AM, Junio C Hamano wrote:
> And for the remaining 20% of those who do not like the canned
> message but still do not need any custom command, I think it is way
> suboptimal to force them to create git-shell-commands directory for
> 47 users his host gives git-shell acc
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> The trouble is that I can't imagine a canned message that everyone
>> will like. (For example, I quite dislike the current one.) That's
>> exactly the situation in which some configurability is helpful.
>
> I am not saying we should have a perf
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>>> Junio C Hamano wrote:
>
Are you shooting for customizability?
>>>
>>> Yes, and the ability to generate the message dynamically.
>>
>> Hmph, if that is the case, wouldn't it be a better direction to
On Mon, Feb 11, 2013 at 1:15 AM, Jonathan Nieder wrote:
> [administrivia: please don't top-post]
> Ethan Reesor wrote:
>
>> Why not have both? That way there is a way to get a customizable
>> response that avoids Junio's complaints and there is a way to do what
>> you are trying to achieve.
>
> Wh
[administrivia: please don't top-post]
Ethan Reesor wrote:
> Why not have both? That way there is a way to get a customizable
> response that avoids Junio's complaints and there is a way to do what
> you are trying to achieve.
What was Junio's complaint?
Jonathan
--
To unsubscribe from this list
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Junio C Hamano wrote:
>>> Are you shooting for customizability?
>>
>> Yes, and the ability to generate the message dynamically.
>
> Hmph, if that is the case, wouldn't it be a better direction to give
> a better help for majority of
Why not have both? That way there is a way to get a customizable
response that avoids Junio's complaints and there is a way to do what
you are trying to achieve.
On Mon, Feb 11, 2013 at 1:09 AM, Jonathan Nieder wrote:
> Ethan Reesor wrote:
>
>>That way, there's a default s
Ethan Reesor wrote:
>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`.
That won't let me imitate gitolite's behavior without a lot of
config file churn:
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 wrote:
> On Mon, Feb 11, 2013 at 12:22 AM, Junio C Hamano wrote:
>> Hmph, if that is the case, wouldn't it be a better direction to give
>> a better help f
On Mon, Feb 11, 2013 at 12:22 AM, Junio C Hamano 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 i
Jonathan Nieder writes:
> Junio C Hamano wrote:
>
>> Are you shooting for customizability?
>
> Yes, and the ability to generate the message dynamically.
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 us
On Sun, Feb 10, 2013 at 05:20:16PM -0800, Jonathan Nieder wrote:
> diff --git a/shell.c b/shell.c
> index 84b237fe..3abc2b84 100644
> --- a/shell.c
> +++ b/shell.c
> @@ -63,10 +63,16 @@ static void cd_to_homedir(void)
>
> static void run_shell(void)
> {
> - int done = 0;
> + int done =
On Sun, Feb 10, 2013 at 08:32:47PM -0800, Jonathan Nieder wrote:
> Junio C Hamano wrote:
>
> > Are you shooting for customizability?
>
> Yes, and the ability to generate the message dynamically.
As far as the default goes, I think the current one is OK, provided
there is an option
On Sun, Feb 10, 2013 at 08:26:09PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
> > On Sun, Feb 10, 2013 at 08:14:04PM -0800, Jonathan Nieder wrote:
>
> >> Only interactive connections. That's the existing behavior.
> >
> > Ah, sorry. I misread the patch. I see now that we already run help,
Junio C Hamano wrote:
> Are you shooting for customizability?
Yes, and the ability to generate the message dynamically.
--
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.
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Jonathan Nieder writes:
>
>>> How about this?
>>>
>>> A patch on top could change the default "git-shell-commands is not
>>> present" message if that seems worthwhile.
>>
>> Hmph.
>>
>> I wonder if rewording the message when git-shell-commmands
Jeff King wrote:
> On Sun, Feb 10, 2013 at 08:14:04PM -0800, Jonathan Nieder wrote:
>> Only interactive connections. That's the existing behavior.
>
> Ah, sorry. I misread the patch. I see now that we already run help, and
> this is just making the exit value significant. In that case, yeah, I
>
On Sun, Feb 10, 2013 at 08:14:04PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
> > On Sun, Feb 10, 2013 at 05:20:16PM -0800, Jonathan Nieder wrote:
>
> >> +When run interactively (with no arguments), 'git-shell' will
> >> +automatically run `~/git-shell-commands/help` on startup, provided it
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> How about this?
>>
>> A patch on top could change the default "git-shell-commands is not
>> present" message if that seems worthwhile.
>
> Hmph.
>
> I wonder if rewording the message when git-shell-commmands directory
> is not there may be a bett
Jeff King wrote:
> On Sun, Feb 10, 2013 at 05:20:16PM -0800, Jonathan Nieder wrote:
>> +When run interactively (with no arguments), 'git-shell' will
>> +automatically run `~/git-shell-commands/help` on startup, provided it
>> +exists. If the 'help' command fails then the interactive shell is
>> +
On Sun, Feb 10, 2013 at 05:20:16PM -0800, Jonathan Nieder wrote:
> > This of course now means that the ~/git-shell-commands should not be
> > empty, since that is where this default command also will be present.
>
> How about this?
I like the general direction this is going, but:
> +When run in
Jonathan Nieder writes:
> How about this?
>
> A patch on top could change the default "git-shell-commands is not
> present" message if that seems worthwhile.
Hmph.
I wonder if rewording the message when git-shell-commmands directory
is not there may be a better first step (which actually could
If I disable git-shell's interactive mode by removing the
~/git-shell-commands directory, then attempts to use 'ssh' with the
git account interactively produce an error message intended for the
administrator:
$ ssh git@myserver
fatal: Interactive git shell is not enabled.
h
35 matches
Mail list logo
