##// END OF EJS Templates
upstream » kallithea
RSS

Clone from https://kallithea-scm.org/repos/kallithea

2 Branches 6 Closed Branches 82 Tags 8777 Commits 0 Forks
Show More
Commit message Age Author Refs
r8776:36a36ebd
i18n: prevent msgmerge fuzzy matching - it is too random
Mads Kiilerich
tip stable
0
r8775:a900f8dc
i18n: updated translation for French Currently translated at 100.0% (1080 of 1080 strings)
Étienne Gilli
stable
0
r8774:6934c581
i18n: updated translation for Chinese (Simplified) Currently translated at 38.9% (421 of 1080 strings)
qy117121
stable
0
r8773:7a6736f3
i18n: reorder messages after 2e1059de6751
Mads Kiilerich
stable
0
r8772:2e1059de
repo groups: make it possible to remove own explicit permissions, now when group owners always have admin permissions Until recently, group owners very given explicit admin permissions on repo group, and special care was taken to make sure they didn't remove themselves. Now we always give admin permissions to owners, and don't care about the explicit permissions. We no longer add them when creating groups or changing owner. There is no migration step to remove redundant permissions, but we should allow group admins to remove them. This change will thus remove the mechanism for preventing removal of own/owner permissions.
Mads Kiilerich
stable
0
r8771:1aa109ae
repo group: stop giving explicit admin permission to owner on create The repo owner will always get admin permissions when computing permissions, so there is no need to assign these permissions explicitly. Note: Permissions that has been added in the past are redundant but will be kept.
Mads Kiilerich
stable
0
r8770:e27ff6a9
auth: always consider the repo group owner an admin when computing it's permissions When computing repo group permissions in repository_group_permissions(), always give admin permissions to the group owner. That is similar to how repository_permissions() gives admin permissions to the repo owner. The extra computation shouldn't cause any extra database hits or make the computation more complex or expensive, so that should be fine for stable. Note: This will leave behind some (automaticly added) explicit permissions. I consider this a very minor glitch, not worth addressing.
Mads Kiilerich
stable
0
r8769:511b20a6
tests: skip reading Git system and global configuration in test_vcs_operations The parent changeset reduced the dependency on global configuration and made it possible to run tests without any global git configuration. But it is still unfortunate to even look at the global configuration when running tests. Global configuration is already disabled for Mercurial by setting HGRCPATH. Now do something similar for Git. According to the git man page, GIT_CONFIG_GLOBAL and GIT_CONFIG_SYSTEM set to /dev/null will make Git skip reading the configuration files on all platforms. Note that the GIT_CONFIG variables were introduced in Git 2.32.0, so this will not work with all the Git versions supported by Kallithea.
Manuel Jacob
stable
0
r8768:d6d3cb59
tests: stabilize Git committer in test_vcs_operations Git tries to find out name and email in this order: 1. The author can be set e.g. via the `--author` option of `git commit`. 2. If set, the environment variables GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL are taken. 3. If set, various (global) config files are considered. 4. Unless disabled by the user.useconfigonly config, the names and emails are inferred from various system sources such as various fields from /etc/passwd, /etc/mailname and the environment variable EMAIL. The author can be provided on the command line (1), but that is not possible for the committer. It is not an option to modify Git’s configuration files, so the result of (3) depends on the system the tests run on, which should be avoided. A follow-up patch will try to instruct Git to not read the system Git configuration files. (4) is also system-dependent. On some systems, (4) is disabled in the Git configuration. If enabled, Git will try to infer the committer name from the gecko field in /etc/passwd, but will fail if it is empty. The previous code passed the environment variable EMAIL to provide the corresponding email address. By passing the names and emails via (2), we can set the author and committer name and email uniformly and prevent Git from using the system-dependent ways (3) and (4). This will replace the use of of EMAIL. The environment variables were introduced in 2005, so there should be no backwards compatibility problems. The tests will specify --author explicitly in the cases where the actual name matters. We just need default values that can be used for committing when we don't care. We set it as static defaults to: Author: test_regular <test_regular@example.com> Commit: test_admin <test_admin@example.com> Based on changes and research by Manuel Jacob <me@manueljacob.de>.
Mads Kiilerich
stable
0
r8767:0a9ddb8c
setup: avoid setuptools 67 - it can't handle celery's broken pytz dependency With setuptools 67 or later, launching Kallithea fails as: $ gearbox serve -c my.ini --reload 15:56:54,111 ERROR [gearbox] Expected closing RIGHT_PARENTHESIS pytz (>dev) ~^ The `packaging` vendored in setuptools cannot handle the broken syntax `Requires-Dist: pytz (>dev)` in venv/lib/python3.11/site-packages/celery-5.0.5.dist-info/METADATA . The old celery version currently used by Kallithea is wrong, and setuptools has moved on after a reasonable grace period. We thus have to work around and avoid latest setuptools. See https://github.com/pypa/setuptools/issues/3889 .
Mads Kiilerich
stable
0
< 1 2 3 4 5 6 7 .. 878 >

Kallithea README

About

Kallithea is a fast and powerful management tool for Mercurial and Git with a built-in push/pull server, full text search and code-review. It works on HTTP/HTTPS and SSH, has a built-in permission/authentication system with the ability to authenticate via LDAP or ActiveDirectory. Kallithea also provides simple API so it's easy to integrate with existing external systems.

Kallithea is similar in some respects to GitHub or Bitbucket, however Kallithea can be run as standalone hosted application on your own server. It is open-source and focuses more on providing a customised, self-administered interface for Mercurial and Git repositories. Kallithea works on Unix-like systems and Windows.

Kallithea was forked from RhodeCode in July 2014 and has been heavily modified.

Installation

Kallithea requires Python 3 and it is recommended to install it in a virtualenv. Official releases of Kallithea can be installed with:

pip install kallithea

The development repository is kept very stable and used in production by the developers -- you can do the same.

Please visit https://docs.kallithea-scm.org/en/latest/installation.html for more details.

There is also an experimental Puppet module for installing and setting up Kallithea. Currently, only basic functionality is provided, but it is still enough to get up and running quickly, especially for people without Python background. See https://docs.kallithea-scm.org/en/latest/installation_puppet.html for further information.

Source code

The latest sources can be obtained from https://kallithea-scm.org/repos/kallithea.

Kallithea features

  • Has its own middleware to handle Mercurial and Git protocol requests. Each request is authenticated and logged together with IP address.
  • Built for speed and performance. You can make multiple pulls/pushes simultaneously. Proven to work with thousands of repositories and users.
  • Supports HTTP/HTTPS with LDAP, AD, or proxy-pass authentication.
  • Supports SSH access with server-side public key management.
  • Full permissions (private/read/write/admin) together with IP restrictions for each repository, additional explicit forking, repositories group and repository creation permissions.
  • User groups for easier permission management.
  • Repository groups let you group repos and manage them easier. They come with permission delegation features, so you can delegate groups management.
  • Users can fork other users repos, and compare them at any time.
  • Built-in versioned paste functionality (Gist) for sharing code snippets.
  • Integrates easily with other systems, with custom created mappers you can connect it to almost any issue tracker, and with a JSON-RPC API you can make much more.
  • Built-in commit API lets you add, edit and commit files right from Kallithea web interface using simple editor or upload binary files using simple form.
  • Powerful pull request driven review system with inline commenting, changeset statuses, and notification system.
  • Importing and syncing repositories from remote locations for Git and Mercurial.
  • Mako templates let you customize the look and feel of the application.
  • Beautiful diffs, annotations and source code browsing all colored by pygments. Raw diffs are made in Git-diff format for both VCS systems, including Git binary-patches.
  • Mercurial and Git DAG graphs and Flot-powered graphs with zooming and statistics to track activity for repositories.
  • Admin interface with user/permission management. Admin activity journal logs pulls, pushes, forks, registrations and other actions made by all users.
  • Server side forks. It is possible to fork a project and modify it freely without breaking the main repository.
  • reST and Markdown README support for repositories.
  • Full text search powered by Whoosh on the source files, commit messages, and file names. Built-in indexing daemons, with optional incremental index build (no external search servers required all in one application).
  • Setup project descriptions/tags and info inside built in DB for easy, non-filesystem operations.
  • Intelligent cache with invalidation after push or project change, provides high performance and always up to date data.
  • RSS/Atom feeds, Gravatar support, downloadable sources as zip/tar/gz.
  • Optional async tasks for speed and performance using Celery.
  • Backup scripts can do backup of whole app and send it over scp to desired location.
  • Based on TurboGears2, SQLAlchemy, Whoosh, Bootstrap, and other open source libraries.
  • Uses PostgreSQL, SQLite, or MariaDB/MySQL databases.

License

Kallithea is released under the GPLv3 license. Kallithea is a Software Freedom Conservancy project and thus controlled by a non-profit organization. No commercial entity can take ownership of the project and change the direction.

Kallithea started out as an effort to make sure the existing GPLv3 codebase would stay available under a legal license. Kallithea thus has to stay GPLv3 compatible ... but we are also happy it is GPLv3 and happy to keep it that way. A different license (such as AGPL) could perhaps help attract a different community with a different mix of Free Software people and companies but we are happy with the current focus.

Community

Kallithea is maintained by its users who contribute the fixes they would like to see.

Get in touch with the rest of the community:

Online documentation

Online documentation for the current version of Kallithea is available at https://docs.kallithea-scm.org/en/stable/. Documentation for the current development version can be found on https://docs.kallithea-scm.org/en/default/.

You can also build the documentation locally: go to docs/ and run:

make html

Note

You need to have Sphinx installed to build the documentation. If you don't have Sphinx installed you can install it via the command: pip install sphinx .

Migrating from RhodeCode

Kallithea 0.3.2 and earlier supports migrating from an existing RhodeCode installation. To migrate, install Kallithea 0.3.2 and follow the instructions in the 0.3.2 README to perform a one-time conversion of the database from RhodeCode to Kallithea, before upgrading to this version of Kallithea.