3 ms·

Git 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, w

Git 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 ago
Oh 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/

frakkingcylons 13y ago

Oh 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/