Repository navigation
Conversation
The release skill's verification pass found each of these against the v0.78.0 binary rather than the diff. `--output`: v0.78.0 already replaced an existing destination — only the unshipped #4153 prompted first — so the entry described as new something a 0.78.0 user already had. What actually changes for them is that the config being migrated is accepted instead of refused, and its `approved-commands` move to approvals.toml first. It cites #4204 alone; #4153's behavior is gone. Diff display config: `wt step prune` deleted the branch too, not just `wt remove`; the poisoning command was any Worktrunk command run from the subdirectory, not only the removal — `wt list` from `docs/` then `wt remove` from the root was enough. And plumbing does honor `submodule.<name>.ignore`, which `PlumbingDiff::args` overrides with `--ignore-submodules=none`, so the sentence claiming plumbing ignores that configuration is wrong and goes. `wt config create` replacing a dangling symlink at the config path with a regular file was fixed in #4204 with no entry of its own. Ranking: the diff-display entry sits below three Fixed entries that reach more readers, and above the empty-sections warning fix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
worktrunk-bot
left a comment
There was a problem hiding this comment.
Under diff.relative, the integration check is one diff-tree --quiet from the merge base to the branch tip (has_added_changes_by_sha in src/git/repository/integration.rs), so it reports "no changes" only when every changed path sits outside the cwd — a single path inside makes the diff non-empty and the branch survives. Dropping "entirely" widens the stated trigger to any subdirectory the changes sit outside, which overstates how far the branch deletion reached; .claude/skills/release/SKILL.md keeps the qualifier in its own exemplar under "Name the conditions a bug needed, so the entry carries its magnitude". Since this text publishes as the release body at the tag, the suggestion inline restores it while keeping this PR's "a Worktrunk command" correction.
Verification tested the negative case: a branch touching one file inside the subdirectory and one outside is retained by v0.78.0 run from there. Without 'entirely' the entry reads as though any change outside the subdirectory triggered the deletion, which overstates it. Dropping the 'hid … from the integration check' mechanism pays for the word and takes the entry to 70. The entry also moves above auto-staging, an over-long warning listing — the prior ordering put a cosmetic fix over one whose old behavior deleted a branch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Only `submodule.<name>.ignore = all` hides a gitlink bump; `dirty`, `untracked` and `none` all leave the branch intact on v0.78.0, in both config locations. The repo's own test says so too — `test_submodule_bump_survives_submodule_ignore` sets `all`, and `integration.rs` names that value. Saying the setting was merely "set" overstates which configurations the deletion reached. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
WorkingTree::has_staged_changes still runs porcelain `git diff --cached --quiet`, which follows `submodule.<name>.ignore = all`, so "no longer changes what Worktrunk reads" claims more than 0.79.0 delivers. The call is byte-identical in v0.78.0, so this is pre-existing rather than a regression, but the entry should not say it is fixed. The headline now names the two surfaces the release actually fixed, which is what the body already describes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Verification passes against the v0.78.0 binary found five inaccuracies in the 0.79.0 changelog. The tag publishes this text as the GitHub release body, so each is corrected here rather than after the fact.
--outputentry described behavior 0.78.0 already had. Replacing an existing destination is not new; what config: write the path the user named, and check every config write the same way #4204 changed is that--outputpointed at the config being migrated is no longer refused. The entry now claims only that, and moves out of the shared bullet with fix(config): refuse to overwrite an existing file withwt config update --output#4153.wt step pruneshares the integration-check defect, not justwt remove— both reach it through the same check, so both are named.has-added-changescache, not only the removal itself, so the condition reads "a Worktrunk command run from a subdirectory" rather than "the command".submodule.<name>.ignore = alltriggers it.untrackedanddirtyleave a submodule pointer bump visible, so the value is named.git statushas no plumbing equivalent. Scoped to the prompts and the integration check, which is what this release fixes.Two further changes: "entirely" is restored to the
diff.relativecondition, where a repro confirmed it load-bearing (a branch also touching a file inside the subdirectory is retained), andwt config create's dangling-symlink fix from #4204 gets the entry it was missing.Entry order within Fixed follows reader interest; no code changes.
🤖 Generated with Claude Code