vole
Clone
Read only, no credentials:
https://rodent.software/git/vole.git
Write over SSH with a registered key:
git clone ssh://git@0.0.0.0:2222/vole.git
A free and open-source forge that lives in your Git repo.
Let the CLI do what the browser does for the same account
7e0b5950c190caf11089e1aaac10f18678074fed · Keenan Nemetz · 6d ago · parent 6e1fca51
Let the CLI do what the browser does for the same account A contributor could file an issue, comment, manage the item it wrote, and open a change from its own branch — but only in the browser, because a push to `refs/heads/vole` required `maintain`. The role was not the reason: the hook had no per-path authorization for that branch, so the role gate stood in for one. The per-path checker is now applied to every session, not only to run credentials. It asks the ACL the questions the browser's forms ask — CanDiscuss, CanOpenRequest, CanTriage, CanApprove — so a contributor's key can write what a contributor may write, and a maintainer's key is unchanged. A non-maintainer's new file must name that account as its author, which is what the browser does for it; a maintainer keeps writing an imported issue under its original author, because that is a trust decision rather than a capability. Creating the issues branch still needs a maintainer, as it does from the browser, and an approval still cannot approve its author's own change — the tree validator already refused that, and now every transport gets the same answer. The one rule that moved is self-approval for a maintainer's push, which is now refused earlier rather than only at the landing gate. With the branch no longer bundled into `maintain`, CONTRIBUTING and the guides stop telling contributors to use the web. Both transports are one authorization model. Part of #168, stacked on #167, which built the checker this generalises.
CONTRIBUTING.md +9−6
| @@ -50,9 +50,11 @@ order in the `vole` branch's history, so an admin redaction that rewrites that | |||
| 50 | 50 | history renumbers what came after it. The 8-character prefixes shown by | |
| 51 | 51 | `%(shortid)` can also collide: they are mostly timestamp. | |
| 52 | 52 | ||
| 53 | The CLI writes the `vole` metadata branch directly, so issue and comment writes | ||
| 54 | need `maintain` access. A contributor without that role files issues and | ||
| 55 | comments in the browser instead. | ||
| 53 | The CLI writes the `vole` metadata branch directly, and the push boundary applies | ||
| 54 | the same per-path rules the browser's forms do: an account that may discuss files | ||
| 55 | an issue and comments, an author manages the item it wrote, and a maintainer | ||
| 56 | triages any of them. A contributor can therefore use the CLI as well as the | ||
| 57 | browser. | ||
| 56 | 58 | ||
| 57 | 59 | File an issue with a body file for multiline Markdown: | |
| 58 | 60 | ||
| @@ -126,9 +128,10 @@ Important differences from a GitHub-style forge: | |||
| 126 | 128 | ||
| 127 | 129 | - The `vole` metadata branch is maintained by Vole. Do not hand-edit it or | |
| 128 | 130 | force-push it. | |
| 129 | - A contributor may only push under `refs/heads/contrib/<account>/`. | ||
| 130 | Contributors use the web to open change requests; the CLI `change new` | ||
| 131 | writes the metadata branch directly and needs `maintain`. | ||
| 131 | - A contributor may push under `refs/heads/contrib/<account>/`, and may write the | ||
| 132 | `vole` metadata branch with the same capabilities it has in the browser: file | ||
| 133 | issues and comments, manage its own items, and open a change from its own | ||
| 134 | branch. It cannot approve, triage somebody else's item, or write a release. | ||
| 132 | 135 | - Protected branches require an approved change request naming the exact head | |
| 133 | 136 | commit. A request that follows a branch names that branch's current tip, and a | |
| 134 | 137 | push to the branch moves it. CI checks may also be required. Do not try to | |