Decision: does the two-commit test-then-fix shape survive squash-merge into next? #25

Open
opened 2026-08-10 15:55:10 +02:00 by clawbot · 0 comments
Collaborator

#21 is deliberately two commits — 3dbe695 adds tests that fail against the pre-existing code, 430bd76 fixes it, with no assertion changes between them. Its body says: "Do not squash-merge; squashing destroys that shape."

The current workflow says the manager squash-merges every issue PR into next. Those two rules cannot both hold here.

Options:

  1. Squash anyway. One commit per issue on next stays universal. The proof-of-failure commit is lost from history, though it is still recorded in the PR.
  2. Allow a rebase-merge exception where a PR's commits are a deliberate demonstration. Needs a rule for when it applies, or it becomes a way to opt out of squashing.
  3. Keep the shape, drop the claim — squash, and record the before/after evidence in the PR body instead of in history.

My read is 2, narrowly: the test-then-fix pair is the only case where the commit boundary carries evidence that the squashed commit cannot. But this is a workflow rule, so it is yours.

Assigning to you for the ruling; nothing is blocked meanwhile — the PR needs a rebase regardless.

https://git.eeqj.de/sneak/simplelog/pulls/21 is deliberately two commits — `3dbe695` adds tests that fail against the pre-existing code, `430bd76` fixes it, with no assertion changes between them. Its body says: **"Do not squash-merge; squashing destroys that shape."** The current workflow says the manager squash-merges every issue PR into `next`. Those two rules cannot both hold here. Options: 1. **Squash anyway.** One commit per issue on `next` stays universal. The proof-of-failure commit is lost from history, though it is still recorded in the PR. 2. **Allow a rebase-merge exception** where a PR's commits are a deliberate demonstration. Needs a rule for when it applies, or it becomes a way to opt out of squashing. 3. **Keep the shape, drop the claim** — squash, and record the before/after evidence in the PR body instead of in history. My read is 2, narrowly: the test-then-fix pair is the only case where the commit boundary carries evidence that the squashed commit cannot. But this is a workflow rule, so it is yours. Assigning to you for the ruling; nothing is blocked meanwhile — the PR needs a rebase regardless.
sneak was assigned by clawbot 2026-08-10 15:55:10 +02:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/simplelog#25