A Django application to browse a Git repository and build Web applications on top of it.
The Django storage supports most of the storage API: open, save, exists, listdir… missing features include mtime, ctime and atime since Git doesn’t directly store those values.
The storage is limited just as any Git repository. It is designed for a single writer and many readers. Concurrent writing is not even tested. No effort was made to optimise read access either. Your mileage may vary.
The storage is an interesting proof-of-concept but even the rest of GitStorage loads Git objects directly.
Add metadata to the blob, only mimetype for now.
Only admin users are allowed by default. Share access to a tree and its blobs (but not its subtrees) to a regular user.
These views are designed as the foundation of class-based views like TemplateView and FormView, and your own business logic.
The main view that dispatches to a view dedicated to each Git object type (namely blob and tree).
Not actually a mixin since it is functional but the dedicated views are mixins (see below).
Default view for a tree, lists its contents.
Default view for a blob, displays its information.
Preview the current blob in the browser if possible, download it otherwise.
Force download the current blob.
Delete the current blob.
Upload a new file to the current tree (as a blob).
Browse the repository to compute metadata for each blob not known yet.
To call after pushing new commits to the repository, ideally from a Git hook.
Cleaning up of metadata for orphan blobs is not handled.
A minimal Django project is shipped to run the test suite. Try make coverage (100% at the time of this writing).
GitStorage uses South.
GitStorage is copyright Bors Ltd with ideas from the PyGit2 project.
GitStorage is published under the GNU General Public License version 3.
TODO: Figure out how to actually get changelog content.
Changelog content for this version goes here.