0

I was looking for a solution for hosting a private (closed source) multi-user collaboration git repository on standard scripting-enabled webspace, which would then be accessible through HTTP, but I couldn't find one.

This same thing exists for SSH (gitolite) and it has proven to be a worthy tool. However, SSH is not available on many webspaces and even if it is, the webspace owner will not want to share his login credentials, because this would be a major security issue.

All scripts that I found deal with viewing the git repository on various ways, usually making the repository public. I couldn't find a script for accessing the repository during the development process for read and write operations.

I think it should be simple to create a server-side script, which takes care of enforcing access rights to a multi-user git repository on a server. That way, read and write operations could be handled on standard scripting-enabled webspace with HTTP-access, which would result in way lower costs and easier setup of a server-based, fully functional git repository for multi-user collaboration.

I wonder why this is not a standard solution for repositories. The current HTTP access to git repositories is not optimized, and widely used only for read access, because enabling the write access is too difficult or the technology (WebDAV) is not available on existing infrastructure.

Is there an intrinsic problem with this idea, or has a good solution for this just not yet been written?

Daniel S.
  • 6,458
  • 4
  • 35
  • 78

2 Answers2

0

The tool cgit is opensource and can be used to setup your own hosted repositories. It provides a web frontend to one or more git repositories on your server via CGI.

It is also possible to set up user authentication/authorisation. See here for example.

Community
  • 1
  • 1
poida
  • 3,403
  • 26
  • 26
0

"Unoptimized HTTP access" is a thing of the past. The speed of fetching/pushing using SmartHTTP is roughly the same as with SSH if not better (due to not encrypting the traffic, unless TLS is used for HTTP).

WebDAV is not needed for pushes over HTTP: the native Git's HTTP backend supports all kinds of operations. The authentication is provided by the web server, and can be set up in a way to be rather flexible and, say, allow unauthenticated fetches but authenticated pushes.

Gitolite v3 can also be put between the web server and the Git's HTTP backend to get the best of both worlds. I have this working on Debian Squeeze: gitolite v3 accessed both via SSH and via HTTP.

See this for more info.

kostix
  • 51,517
  • 14
  • 93
  • 176