|
|
|
|
# dehub
|
|
|
|
|
|
|
|
|
|
dehub aims to provide all the features of a git hosting platform, but without
|
|
|
|
|
the hosting part. These features include:
|
|
|
|
|
|
|
|
|
|
**User management** - Authentication that commits come from the user they say
|
|
|
|
|
they do, and fine-grained control over which users can do what.
|
|
|
|
|
|
|
|
|
|
**Pull requests and issues** - Facilitation of discussion via comment commits,
|
|
|
|
|
and fine-grained (down to the file level) sign-off requirements.
|
|
|
|
|
|
|
|
|
|
**Tags and releases** - Mark releases in the repo itself, and provide
|
|
|
|
|
immutable and verifiable git tags so there's never any funny business. (Not yet
|
|
|
|
|
implemented)
|
|
|
|
|
|
|
|
|
|
**Plugins**: Extend all aspects of dehub functionality via executables managed
|
|
|
|
|
in the repo itself (in the same style as git hooks). (Not yet implemented)
|
|
|
|
|
|
|
|
|
|
## Key Concepts
|
|
|
|
|
|
|
|
|
|
To implement these features, dehub combines two key concepts:
|
|
|
|
|
|
|
|
|
|
First, repo configuration is defined in the repo itself. A file called
|
|
|
|
|
`.dehub/config.yml` contains all information related to user accounts, their pgp
|
|
|
|
|
keys, branch and file level access controls, and more. Every commit must adhere
|
|
|
|
|
to the configuration of its parent in order to be considered _verifiable_. The
|
|
|
|
|
configuration file is committed to the repo like any other file would be, and so
|
|
|
|
|
is even able to define the access controls on itself.
|
|
|
|
|
|
|
|
|
|
Second, the commit message of every dehub commit contains a YAML encoded
|
|
|
|
|
payload, which allows dehub to extend git and provide multiple commit types,
|
|
|
|
|
each with its own capabilities and restrictions. Some example dehub commit types
|
|
|
|
|
are `change` commits, `comment` commits, and `credential` commits.
|
|
|
|
|
|
|
|
|
|
## Infrastructure (or lack thereof)
|
|
|
|
|
|
|
|
|
|
Because a dehub project is entirely housed within a traditional git project,
|
|
|
|
|
which is merely a collection of files, any existing git or network filesystem
|
|
|
|
|
infrastructure can be used to host any dehub project:
|
|
|
|
|
|
|
|
|
|
* The most barebones [git
|
|
|
|
|
daemon](https://git-scm.com/book/en/v2/Git-on-the-Server-Git-Daemon) server
|
|
|
|
|
(with a simple pre-receive hook set up).
|
|
|
|
|
|
|
|
|
|
* A remote SSH endpoint.
|
|
|
|
|
|
|
|
|
|
* A mailing list (aka the old school way).
|
|
|
|
|
|
|
|
|
|
* Network file syncing utilities such as dropbox,
|
|
|
|
|
[syncthing](https://github.com/syncthing/syncthing), or
|
|
|
|
|
[NFS](https://en.wikipedia.org/wiki/Network_File_System).
|
|
|
|
|
|
|
|
|
|
* Existing git project hosts like GitHub, Bitbucket, or Keybase.
|
|
|
|
|
|
|
|
|
|
* Decentralized filesystems such as IPFS. (Not yet implemented)
|
|
|
|
|
|
|
|
|
|
## Getting Started {#getting-started}
|
|
|
|
|
|
|
|
|
|
The dehub project itself can be found by cloning
|
|
|
|
|
`https://dehub.dev/src/dehub.git`.
|
|
|
|
|
|
|
|
|
|
Installation of the dehub tool is currently done via the `go get` command:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
go get -u -v dehub.dev/src/dehub.git/cmd/dehub
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
This will install the binary to your `$GOBIN` path, which you'll want to put in
|
|
|
|
|
your `$PATH`. Run `go env` if you're not sure where your `$GOBIN` is.
|
|
|
|
|
|
|
|
|
|
Once installed, running `dehub -h` should show you the help output of the
|
|
|
|
|
command. You can continue on to the tutorials if you're not sure where to go
|
|
|
|
|
from here.
|
|
|
|
|
|
|
|
|
|
### Tutorials {#tutorials}
|
|
|
|
|
|
|
|
|
|
The following tutorials will guide you through the basic usage of dehub. Note
|
|
|
|
|
that dehub is in the infancy of its development, and so a certain level of
|
|
|
|
|
profiency with git and PGP is required in order to follow these tutorials.
|
|
|
|
|
|
|
|
|
|
* [Tutorial 0: Say Hello!](/docs/tut0.html)
|
|
|
|
|
* [Tutorial 1: Create Your Own Project](/docs/tut1.html)
|
|
|
|
|
* [Tutorial 2: Access Controls](/docs/tut2.html)
|
|
|
|
|
* [Tutorial 3: Commit Sign-Off](/docs/tut3.html)
|
|
|
|
|
|
|
|
|
|
### Documentation
|
|
|
|
|
|
|
|
|
|
The [SPEC](/docs/SPEC.html) is the best place to see every possible nitty-gritty
|
|
|
|
|
detail of how dehub works. It attempts to be both human-readable and exhaustive
|
|
|
|
|
in its coverage.
|
|
|
|
|
|
|
|
|
|
### Other links
|
|
|
|
|
|
|
|
|
|
[ROADMAP](/docs/ROADMAP.html) documents upcoming features and other work
|
|
|
|
|
required on the project. If you're looking to contribute, this is a great place
|
|
|
|
|
to start.
|
|
|
|
|
|
|
|
|
|
[dehub-remote](/cmd/dehub-remote/) is a simple docker image which can be used to
|
|
|
|
|
host a remote dehub project over http(s). The endpoint will automatically verify
|
|
|
|
|
all pushed commits.
|
|
|
|
|
|
|
|
|
|
[git-http-server](/cmd/git-http-server/) is a small server which makes a git
|
|
|
|
|
repo's file tree available via http. It will automatically render markdown files
|
|
|
|
|
to html as well. git-http-server is used to render dehub's website.
|
