@ -46,14 +46,14 @@ platforms like IPFS.
### Example ### Example
MyProject wants to ensure that at least 2 of the 3 maintainers sign off on a MyProject wants to ensure that at least 2 of the 3 maintainers sign off on a
commit before the commit can be placed into the `trunk ` branch (dehub's commit before the commit can be placed into the `main ` branch (dehub's
equivalent of the `master` branch). MyProject's repo would contain a equivalent of the `master` branch). MyProject's repo would contain a
`.dehub/config.yml` file with the following access controls set:`.dehub/config.yml` file with the following access controls set:
``` ```
# ... # ...
access_controls: access_controls:
- branch_pattern: trunk - branch_pattern: main
change_access_controls: change_access_controls:
# matches all files, but could be used for more fine-grained control # matches all files, but could be used for more fine-grained control
- file_path_pattern: "**" - file_path_pattern: "**"
@ -66,7 +66,7 @@ access_controls:
count: 2 count: 2
``` ```
A commit in the `trunk ` branch would have a message with the following form: A commit in the `main ` branch would have a message with the following form:
``` ```
This is the first line of the commit message. It remains human readable This is the first line of the commit message. It remains human readable
@ -98,14 +98,14 @@ credentials:
``` ```
The `credentials` contains signatures of both the commit message and its The `credentials` contains signatures of both the commit message and its
changes, allowing it to be added to the `trunk ` . A simple git hook is all that's changes, allowing it to be added to the `main ` . A simple git hook is all that's
needed to verify commits in `trunk ` when they are pushed or pulled. needed to verify commits in `main ` when they are pushed or pulled.
## dehub Thread Branches ## dehub Thread Branches
The `trunk ` branch is the project's source-of-truth. Other branches, called The `main ` branch is the project's source-of-truth. Other branches, called
threads, are used to coordinate new changes, and then coalesce those changes threads, are used to coordinate new changes, and then coalesce those changes
into a commit suitable for `trunk ` . into a commit suitable for `main ` .
### Example ### Example
@ -126,7 +126,7 @@ credentials:
account: alice account: alice
# Note that this commit does not have enough credentials to be allowed in the # Note that this commit does not have enough credentials to be allowed in the
# trunk branch. # main branch.
``` ```
Bob sees the new thread branch and looks through it. He pushes the following Bob sees the new thread branch and looks through it. He pushes the following
@ -174,7 +174,7 @@ credentials:
account: alice account: alice
# Note that this commit does not have enough credentials to be allowed in the # Note that this commit does not have enough credentials to be allowed in the
# trunk branch. # main branch.
``` ```
Bob, happy with these changes, pushes a commit to the thread which adds his own Bob, happy with these changes, pushes a commit to the thread which adds his own
@ -199,23 +199,23 @@ can do once all the required credentials are available.
To coalesce, the following is done: All file changes in the branch are squashed To coalesce, the following is done: All file changes in the branch are squashed
into a single change commit, using the latest commit message which was pushed by Alice. into a single change commit, using the latest commit message which was pushed by Alice.
Bob's signature is added to the change commit message as a credential. The Bob's signature is added to the change commit message as a credential. The
commit can then be pushed to `trunk ` (because it now has two credentials) and commit can then be pushed to `main ` (because it now has two credentials) and
`featureBranch` can be deleted.`featureBranch` can be deleted.
## Pre-emptively Answered Questions ## Pre-emptively Answered Questions
**How can I trust that the git history I've received is legitimate?** **How can I trust that the git history I've received is legitimate?**
Each commit in `trunk ` can have its credentials verified locally. Credentials Each commit in `main ` can have its credentials verified locally. Credentials
are currently provided by pgp signatures, so your trust in the git chain can be are currently provided by pgp signatures, so your trust in the git chain can be
as strong as your trust in those signatures. Support for other kinds of as strong as your trust in those signatures. Support for other kinds of
credentials (e.g. keybase signatures) will increase the number of options for credentials (e.g. keybase signatures) will increase the number of options for
trust the user has. trust the user has.
**Why `trunk ` ?** **Why `main ` ?**
The primary branch in most git projects is called `master` . It makes sense to The primary branch in most git projects is called `master` . It makes sense to
use a different one, `trunk ` , for dehub, since the commits on it will be use a different one, `main ` , for dehub, since the commits on it will be
following a specific protocol which is not compatible with most `master` following a specific protocol which is not compatible with most `master`
branches. By having a different primary branch convention we can prevent undue branches. By having a different primary branch convention we can prevent undue
conflict, as well as make it easy to tell at a glance what kind of project is conflict, as well as make it easy to tell at a glance what kind of project is
mediocregopher
4 years ago