On Mon, Feb 11, 2013 at 7:45 AM, Konstantin Khomoutov
wrote:
[...]
> OK, here's the sketch.
> On the server, in the home directory of your "git" user, you create a
> wrapper around git-receive-pack, like this:
>
> # mkdir ~git/git-shell-commands
> # cat >~git/git-shell-commands/git-receive-new-rep
On Mon, Feb 11, 2013 at 11:27 AM, Jeff King wrote:
[...]
> We talked about this a long time ago. One problem is that it's
> inherently unportable, as the procedure to make a repo is potentially
> different on every server (and certainly that is the case between a
> regular user running stock git a
even have
> the same UID) so that they could share the files they create (subject to
> active umasks of processes run as both users though).
I thought about the secondary user idea. I decided that trying to make
my own command would be more fun.
--
Ethan Reesor (Gmail)
--
To unsubsc
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)
should not go in their home directory to begin
> with, no?
I know nothing of the security issues, but why not have a
/etc/git-shell-commands?
--
Ethan Reesor (Gmail)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.or
n that something fails, I want to close the
connection for whatever reason.
So, any reason not to have both (on top of making a better default message)?
--
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
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 wh
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,
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
&g
n
> hang up.
>
> Downside: this will prevent interactive git-shell logins in existing
> setups where the "help" script exits with nonzero status by mistake.
> Hopefully those are rare enough to not cause much trouble in practice.
>
> Reported-by: Ethan Reesor
>
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
-shell-commands should exist and have read and execute access.
If no one with more experience has the time to look into your
suggestion, I will try.
Thanks,
Ethan
On Sun, Feb 10, 2013 at 4:25 PM, Jonathan Nieder wrote:
> Ethan Reesor wrote:
>
>> I have a git user set up on my server. It
12 matches
Mail list logo
