Bithug is a small, experimental Github clone.
-
Git access management
-
Private and public repositories
-
Forking
-
Following/Feed generation
-
SVN import/tracking
-
Kerberos/LDAP support
-
Twitter integration
-
Gravatar support
-
Lightweight (uses Sinatra and Redis)
-
Commit Views / File Views (currently only supports directory views)
-
Better error handling (currently not many error messages for the user)
-
Bug fixes (currently issues browsing old commits/other branches)
-
Experimental switch of persistence layer (possibly to Maglev)
-
AMQ / background jobs for forking/repo creation and such
General pre-requirement | What we used for development/deployment ---------------------------------------------|--------------------------------------------- Unix with a SSH server (we) | Fedora Linux 12 and Mac OSX 10.6 | with OpenSSH. Any Linux/BSD should work. | A decent ruby implementation (>= 1.8.7) | Rubinius 1.0.0-rc2 and JRuby 1.4.0, installed | with RVM. We experienced frequent segmentation | faults with the official Ruby implementation. | A web server | Mongrel. All Rubies ship with Webrick, but it | has poor performance. For deployment, consider | Passenger/Apache. | Redis | Installed from official tar ball on Linux. | Via MacPorts on OSX. | Kerberos Support (optional) | You'll need either to install our patched | krb5-auth* or install ruby ffi. | krb5-auth is the preferred option, but works | only on MRI/REE and Rubinius. | Rubinius, JRuby, MacRuby and Meglav already ship | with ffi. To use the ffi krb5 implementation, | you will have to run 'make' in vendor/simple-krb5/ext | once. You will need the krb5 development headers. | | Git | sudo (port|apt-get|yum|brew) install git-core | * gem install timfel-krb5-auth
All other requirements are shipped with Bithug inside the vendor directory.
git clone git://github.com/rkh/bithug.git cd bithug git submodule init git submodule update
In the projects root directory, create a config.rb
. Inside that file you may configure your Bithug system.
The simplest configuration should look something like this:
Bithug.configure do use :Redis, :host => "127.0.0.1", :port => 6379 # Your redis server use :Git use :Local end
Note that “Local” was mainly used for development (read: there is no admin interface to manage the users, users cannot change their passwords) and it is highly recommended to use either Kerberos or LDAP or both.
If you are inside HPI, it is even easier:
Bithug.configure do use :Redis, :host => "127.0.0.1", :port => 6379 use :Hpi end
A full blown configuration could look like this:
Bithug.configure do # Redis connection use :Redis, :host => "127.0.0.1", :port => 6379 # Git repo support use :Git # Subversion repo support use :Svn # Twitter integration use :Twitter, :consumer_key => "...", :consumer_secret => "..." # LDAP authentication use :Ldap, :host => "ldap.com", :port => 10 # Hostname for git url hostname "example.com" # System user (for urls) git_user "git" # Sets title to hostname ("example.com") title hostname end
Note that names like :Twitter or :Git refer to Modules which represent Bithug extensions. You can easily provide you own, documentation might follow (for now, have a look at the source, lib/bithug/hpi.rb might be a good starting point).
Make sure redis is running.
In the root directory, run
irb -rinit
Ideally, when you install bithug on a server, you would create an unpriviliged git user on that machine. That user should have a private ruby stack with the dependencies, git and bin/bithug-serve need to be in his PATH.
Also, make sure redis is running.
As that user, try something along the lines of
ruby init.rb
or
thin start -D -R config.ru
or
rackup
Starting on another port:
ruby init.rb -p 80
All users will need to authenticate against their supplied public-keys, the bithug shell invoked by bithug-serve will take care of checking access rights and logging repository activity.