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
On Sun, Feb 10, 2013 at 11:17:24PM -0800, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
Jonathan Nieder jrnie...@gmail.com 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
Jeff King p...@peff.net writes:
On Sun, Feb 10, 2013 at 11:17:24PM -0800, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
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-disabled
Jonathan Nieder jrnie...@gmail.com 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
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
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
+aborted.
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
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
think
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
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
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, and
this
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 to
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 = 0,
Jonathan Nieder jrnie...@gmail.com 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
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
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
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:
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 jrnie...@gmail.com wrote:
Ethan Reesor wrote:
That way,
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
[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:
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
Jonathan Nieder jrnie...@gmail.com 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
On Mon, Feb 11, 2013 at 2:12 AM, Jonathan Nieder jrnie...@gmail.com 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
Ethan Reesor firelizz...@gmail.com 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,
On Mon, Feb 11, 2013 at 2:22 AM, Junio C Hamano gits...@pobox.com wrote:
Ethan Reesor firelizz...@gmail.com 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
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com 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
29 matches
Mail list logo
