Glitter on top of gitolite
Erlang Shell
Switch branches/tags
Nothing to show
Pull request Compare This branch is 81 commits ahead of auser:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.



This is an erlang binding to gitolite. It is an abstraction to provide flexibility in case we need to swap gitolite for something else. It was originally part of a larger cloud project that provide basic cloud app/deployment workflow, similar to what Heroku offers ( for details).

Basic setup

Glitter runs as either an erlang demaen process or under erlang shell.

This plugin depends on erlang and openssh. Please ensure these dependency be setup beforehand. Only tested using Erlang R14B or above.


  • make clean
  • make install
  • for dependency like edown (generate git mark down), you need erlang source package (erlang_src in ubuntu) to get it compile.

Basic usage

  • Creating Orgnization
  • Creating New Repo
  • Removing Existing Repo
  • Createing New Repo Branch
  • Removing Existing Repo Branch
  • Adding membership and membership rights on a Repo/ Repo Branch
  • Removing membership and membership rights on a Repo/ Repo Branch

Sample Erlang client call code


It is recommend that you set up your own git server and gitolite to test it out on integeration level; preferrably sending command from a separate client machine. Passing/Failing unit tests may not be sufficient to weed out account/process/file ownership issues.

Parse and write configs for the gitolite admin repositories.


Glitter is an erlang application. It consists of three levels. Starting from outmost layer - module glitter - act as a gateway to serve client proper erlang messages; special message formats are assumed to have already properly transformed in prior stage.

Source Code arrangement

Top level Glitter Application --deps (dependency) --ebin (erlang binary) --rel (erlang release configs, metadata files, scripts, release bin) --src (all the subordinate apps)

  • glitter supervisors, applications code -- priv (private files) -- include (state modelled as records, defines etc) <> -- utility (common utility library as an app) --src --include --test -- gl_admin (managment related functions) <>

--test (integeration tests on top app level) --sample (sample client code) *README, rebar, other scripts etc


Parsing is functional. Writing is functional.

No support for branch/directory-specific permissions in repositories. At the moment, I don't really have a need for it, so it probably won't get worked on.