On Mon, Sep 3, 2012 at 6:45 PM, Mark Hills <Mark.Hills@xxxxxxxxxxxxxx> wrote:
> On Mon, 3 Sep 2012, Sitaram Chamarty wrote:
>
>> On Mon, Sep 3, 2012 at 5:17 PM, Konstantin Khomoutov
>> <flatworm@xxxxxxxxxxxxxxxxxxxxx> wrote:
>> > On Mon, 3 Sep 2012 11:21:43 +0100 (BST)
>> > Mark Hills <Mark.Hills@xxxxxxxxxxxxxx> wrote:
>>
>> [snip]
>>
>> >> This is quite cumbersome; we have a large team of devs who use a
>> >> simple 'git clone' to an NFS directory, but we wish to retire NFS
>> >> access.
>>
>> [snip]
>>
>> > gitolite kind of implements this ("wild repos") [1], you could look if
>> > it suits your needs.
>>
>> The simplest conf to do what you want in gitolite is something like this:
>>
>> repo [a-zA-Z0-9]..*
>> C = @all
>> RW+ = @all
>>
>> But of course your *user* authentication will probably change quite a
>> bit, since gitolite runs as one Unix user and merely simulates many
>> "gitolite users", while in the NFS method each of your devs probably
>> has a full login to the server.
>
> I'll check out gitolite, thanks.
>
> We use unix users extensively (groups, permissions etc.) with YP, and this
> works well; a separate permissions scheme is not very desireable.
> The ssh method works very well right now, and nicely transparent. It's
> only the initial clone/creation that is harder than it was over NFS. And
> it prevents the use of git-shell too.
If I had to do this, and didn't want to use gitolite or something like
it, I'd just make a script that will create the repo using an ssh call
then do a 'git push --mirror' to it.
Call it "git-new" or something and train people to use that instead of
"clone" when the repo doesn't even exist yet.
Bound to be easier than the administrative hassle you spoke of in your
other email...
--
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