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.
docs/issues.md +7−3
| @@ -84,8 +84,10 @@ git commit -m "issue: docs page blank" | |||
| 84 | 84 | git push origin vole | |
| 85 | 85 | ``` | |
| 86 | 86 | ||
| 87 | Vole checks the file when you push. If someone else pushed first, the CLI puts | ||
| 88 | your change on top of theirs and tries again. | ||
| 87 | Vole checks the file when you push. The `author` field must be the account you push | ||
| 88 | as unless you hold `maintain`, which is the one place the browser is stricter than a | ||
| 89 | push: a contributor writes as itself. If someone else pushed first, the CLI puts your | ||
| 90 | change on top of theirs and tries again. | ||
| 89 | 91 | ||
| 90 | 92 | ## From the browser | |
| 91 | 93 | ||
| @@ -93,7 +95,9 @@ When browser sign-in is enabled (see [Accounts and access](accounts-and-access.m | |||
| 93 | 95 | a signed-in contributor or maintainer can open an issue or comment from the | |
| 94 | 96 | repository's issue page. The author is the account whose passkey opened the | |
| 95 | 97 | session; the form cannot choose a different name. The change is written with the | |
| 96 | same metadata writer the CLI uses, so it is the same file on the same branch. | ||
| 98 | same metadata writer the CLI uses, so it is the same file on the same branch. A | ||
| 99 | contributor can use this form or the CLI; pre-receive asks the same capabilities the | ||
| 100 | form does, so neither offers more than the other. | ||
| 97 | 101 | ||
| 98 | 102 | ## Using the CLI | |
| 99 | 103 | ||