devhub-tud/java-gitolite-manager

The java-gitolite-manager is a simple and compact Java library which enables developers to manage their gitolite configuration from Java. The aim is to give developers an easy to understand interface to manage repositories, groups and users in gitolite.

java-gitolite-manager's Issues

Support for Gitolite VREF's

So we can use the file size limits (>= 50mb) [https://github.com/devhub-tud/devhub/issues/196], time limits (not really applicable for us) and file restrictions (checkstyle.xml for example).

http://gitolite.com/gitolite/gitolite.html#cb-vrefs
VREF's are a special type of refexes: #8

Gitolite groups extension

Gitolite groups can be extended later on in the configuration file, because the configuration is parsed in 1 pass, groups are automatically expanded when used. Therefore a group might differ between two repositories:

@group user-1

repo name
    RW+ @group

@group user-2

repo name-2
   RW+ @group

For us it would be confusing to support groups this way, because something as: group.addUser(...) suddenly is not that applicable anymore. We should however do something: (1) note that we require groups on the head of the config, (2) log a warning when groups are (re)defined after usage in an existing config.

Support for Gitolite repository groups

Support removing repositories from disk

Currently you can't really delete repositories from gitolite. They remain on disk even after you remove them from the configuration file. We should allow clients to remove repositories from the configuration file and also remove it from disk.

Move classes from nl.minicom.gitolite to nl.tudelft.ewi.gitolite

This project has been transferred to the devhub-tud organization. To ensure this code is consistent with the rest of the code in this organization all classes in nl.minicom.gitolite should be moved to nl.tudelft.ewi.gitolite.

Changes are not pushed to gitolite-admin if merge conflicts between head and remote

Changes are not pushed to gitolite-admin if merge conflicts between head and remote

Release on Devhub nexus server

For the TI1706 course we want students to be able to write tests for devhub. For this it would be easiest if the git-server client and build-server client would be released on the Devhub Nexus maven repository. This is also useful for re-enabling the CI without having to clone all repos, checkout the right branch, and to a maven install.

Support for Gitolite config / option rules

Add support for branch permissions

Gitolite is able to set specific permissions for users and groups on individual branches in git repositories. One example would be to restrict pushing to master to only a few users.

Ability to add/remove git hooks

Users should be able to add or remove git hooks for every repository (excluding gitolite-admin). This will probably require Java-Gitolite-Manager to be run on the git server (preferably on the git user).

Gitolite permission modifiers

Gitolite permission levels C, -, R, RW and RW+ can be extended with the modifiers C, D, M. (Which unfortunately alter the behaviour of other rules).

Add support for pulling remote changes into config

Add support for multithreading

The current architecture only allows changes to made sequentially. This is fine for prototyping, but it forces other developers to work around this problem by building a queueing system in multithreaded environments.

Ideally this queueing concept should be implemented internally. Also it would be nice to implement a transaction-like system where client threads can simple open a transaction on the current model of the configuration and commit any changes they made, as opposed to writing the entire configuration to disk and potentially overwriting changes made by other threads.

Throw IllegalArgumentException on duplicate keys

We already throw exceptions on duplicate key names, but not for duplicate key contents

Gitolite configuration includes

Gitolite repository regexp

Gitolite supports repository rules and groups on repository name patterns. See the following example:

repo FOSS/..*
    # ...rules for repos under FOSS/

@secret     =   secret/..* private/..*
repo @secret
    # ...rules for repos under secret/ and private/

We could consider to support (or at least not break) configurations using these rules.