3 ms·
Do you know how it compares to GitLab? I've been thinking of deploying it when I have a spare weekend. http://gitlab.org/ http://gitlab.org/
by frakkingcylons 13y ago
Do you know how it compares to GitLab? I've been thinking of deploying it when I have a spare weekend.
http://gitlab.org/ http://gitlab.org/
- WestCoastJustin 13y agoGit and Gitolite are command lines tools only. So, you basically install git-daemon, which allows you to run a central git server, and then you have gitolite, which allows you to do user management. GitLab is basically a GUI that fronts this (I'm not sure about their user access implementation though; doubt it is gitolite). There are other tools like Gerrit [1], Gitweb [2], and cgit [3], that you can use to front your git repos though. GitLab is just a really slick one! [1] http://code.google.com/p/gerrit/ http://code.google.com/p/gerrit/ [2] https://git.wiki.kernel.org/index.php/Gitweb https://git.wiki.kernel.org/index.php/Gitweb [3] http://git.zx2c4.com/cgit/ http://git.zx2c4.com/cgit/
- frakkingcylons 13y agoOh I see. I didn't realize how many different tools are available for Git. Thanks!
- csense 13y ago> you basically install git-daemon, which allows you to run a central git server AFAIK, git-daemon is to allow the specific use case of anonymous, public access to git repositories [1]. You don't need it to have a "central git server", though: If you have an ssh account on yourhost.com and a git repo in /home/you/yourproject on that machine, you can simply git clone git+ssh://yourhost.com/home/you/yourproject. Give out multiple ssh keys to that account, and it's a minimal but functional "central git server"! Of course, doing the above the easiest, quickest way, with a single UNIX user account, results in (A) giving git client users access to a shell and (B) giving git client users read/write access to each others' repos. Gitolite uses authorized_keys restrictions to avoid (A) and a clever SSH_ORIGINAL_COMMAND hack to avoid (B). > doubt it is gitolite Gitlab in fact did use Gitolite for actually serving the git client until quite recently. The largest change in 5.0 was reimplementing a subset of Gitolite's functionality and losing the dependency [2]; the project's major version number is still at 5, although 6.0 is promised soon [3]. [1] http://git-scm.com/book/en/Git-on-the-Server-Git-Daemon http://git-scm.com/book/en/Git-on-the-Server-Git-Daemon [2] http://blog.gitlab.org/gitlab-5-dot-0-has-been-released/ http://blog.gitlab.org/gitlab-5-dot-0-has-been-released/ [3] http://blog.gitlab.org/gitlab-5-dot-4-released/ http://blog.gitlab.org/gitlab-5-dot-4-released/
- csense 13y agoI've had experience maintaining a private Gitolite installation; we ended up migrating to Gitlab. Managing SSH keys and repo permissions from the command line was just enough of a learning curve for users (internal developers) that they really didn't like it and tended not to use it unless forced. Gitlab has had much less pushback. Really, it depends on whether your users are more comfortable with the command line or web interface. Also, I found Gitolite to be a bit easier to administer than Gitlab. Gitlab is a Rails web app, with lots of moving parts. Gitolite is essentially a bunch of Perl scripts which use authorized_keys and SSH_ORIGINAL_COMMAND hackery to convince ssh to do the actual authenticating. If you already know and love deploying Rails web apps (I don't), then you might find Gitlab easier.