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.

Make change requests follow branches and allow base retargeting

e050e14a64f6f19c1b1478c4c073d690ef3d3129 · Keenan Nemetz · 13d ago · parent 59464445

Make change requests follow branches and allow base retargeting

A request opened from a branch now follows it: post-receive moves the
request's head to the new tip after an accepted push, so approvals and
checks that named the old tip stop counting. Approvals stay bound to an
exact base and commit; the approval writers now require the base and head
the approver saw, so a push or retarget cannot silently approve a target
nobody reviewed. Merged requests freeze the reviewed head.

Add `vole change update --base` and a Change base control for stacked
requests. A new base changes the diff and therefore invalidates approvals,
which is what retargeting an upper request after its lower branch lands
needs. Base names may now contain slashes.

Also fix a second-boundary flake in the landing test.

CONTRIBUTING.md +9−2

@@ -103,6 +103,12 @@ Then open a Vole change request if the branch should be reviewed:
	103	103	./vole change show <full-id>
	104	104	```
	105	105
		106	A request opened from a branch follows it. Pushing a fixup to that branch moves
		107	the request's head automatically; the approvals and CI results that named the old
		108	head no longer count, so the new tip needs its own approval and checks. You do not
		109	need to run `change update --head` after every push; use it only to repoint an
		110	open request at a different branch, or at a bare commit.
		111
	106	112	Link the issue with `--closes <full-ulid>` (repeatable) when the branch fixes
	107	113	one. That field is what the request page shows and what landing the request
	108	114	closes; `Fixes #<ulid>` in the description is only text. A link may be added or
@@ -117,8 +123,9 @@ Important differences from a GitHub-style forge:
	117	123	Contributors use the web to open change requests; the CLI `change new`
	118	124	writes the metadata branch directly and needs `maintain`.
	119	125	- Protected branches require an approved change request naming the exact head
	120		commit. CI checks may also be required. Do not try to bypass the pre-receive
	121		gate.
		126	commit. A request that follows a branch names that branch's current tip, and a
		127	push to the branch moves it. CI checks may also be required. Do not try to
		128	bypass the pre-receive gate.
	122	129	- Do not approve your own change request. Approval is an attestation by a
	123	130	different account.
	124	131	- CI for a contributor branch does not run until a maintainer allows that exact