Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
"Edward Ned Harvey (blu)" <blu at nedharvey.com> writes: >> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss- >> bounces+blu=nedharvey.com at blu.org] On Behalf Of Chris Johnson >> >> You'll need to get your team to use SSH keys, but that's standard >> practice for most git management systems (e.g. gitolite). > > That may have been true at some point, but now, it works just as well > over http or https. > > I will say, if you use http, the user's password goes across the wire > plaintext. (I confirmed with wireshark.) So my recommendation would > be to plan on using SSL right from the start. Every step along the > way in the gitlab installer, substitute "https" for "http" and so > forth. You could just use git-over-ssh. Give each developer an account on the server and then they can just: git clone ssh://username at git.example.com/path/to/repo.git You might also consider looking at gitolite. It uses ssh as the connection framework (although you can set up HTTP(S) access if you really need it). You store the developer's ssh public keys within gitolite so each user does not necessarily need an actual "account" on the server. In this case everyone would use: git clone ssh://git at git.example.com/path/to/repo.git Using gitolite also provides better access control mechanisms than just using raw accounts. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord at MIT.EDU PGP key available
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |