Re: Clone to an SSH destination

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 3, 2012 at 7:38 PM, Konstantin Khomoutov
<flatworm@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, 3 Sep 2012 14:07:48 +0100 (BST)
> Mark Hills <Mark.Hills@xxxxxxxxxxxxxx> wrote:
>
> [...]
>> > But I'm actually more curious about why you need this in the first
>> > place, there's a bunch of devs where I work as well, but they never
>> > have the need to create new repos on some NFS drive in this manner.
>>
>> Without a command-line onto the filesystem (either local or NFS), how
>> do you create a new repository for a new project?
>>
>> We have a fairly large team on a diverse set of projects. Projects
>> come and go, so it's a burden if the administrator is needed just to
>> create repos.
>>
>> Likewise, it's a step backwards for the developer to need to login
>> themselves over SSH -- whereas 'git clone' is so easy to NFS.
>>
>> > What are your devs doing when they do clone their current working
>> > directory to some NFS location, maybe there's a better way to do it.
>>
>> Most projects start as a small test at some point; eg.
>>
>>   mkdir xx
>>   cd xx
>>   git init
>>   <write some code>
>>   git commit
>>   ...
>>
>> When a project becomes more official, the developer clones to a
>> central location; eg.
>>
>>   git clone --bare . /net/git/xx.git
>>
>> This is the step that is inconvenient if only SSH access is available.
>
> Well, then it looks you want something like github.
> In this case look at some more integrated solution such as Gitlab [1]
> -- I did not try it, but it looks like you import your users there and
> then they can log in, add their SSH keys and create their projects.

Anything web based would be even more overhead than a simple:

    ssh server git init --bare foo/bar.git && git push --mirror
ssh://git/~/foo/bar.git

Gitolite of course is even closer, as we discussed earlier.

> I also think gitolite has some way to actually use regular SSH users
> (or even users coming from a web server which is a front-end for Smart
> HTTP Git transport, doing its own authentication).  This is explained
> in [2], and I hope Sitaram could provide more insight on setting things
> up this way, if needed  (I did not use this feature).

As I said earlier, regardless of how he does it, authentication will
change, since he is no longer using a local (well, locally mounted)
file system as the "server".  That may be "get everyone to send us a
pub key" or "give everyone an http password and use smart http".

In addition, if they choose smart http, they *have to* use gitolite.
Unlike ssh, where that two command sequence above would do it all for
them, there is no eqvt if your git server is behind http.

>
> 1. http://gitlabhq.com/
> 2. http://sitaramc.github.com/gitolite/g2/auth.html
> --
> 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



-- 
Sitaram
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]