mirror of
https://github.com/max-sixty/worktrunk.git
synced 2026-09-14 20:00:38 +08:00
v0.69.1
4667 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Maximilian Roos
|
bd3ebaffde |
Release v0.69.1 (#3577)
Release v0.69.1. A patch release: the Windows code-signing upload fix (`archive: false`, so SignPath receives the real zip rather than a zip-of-a-zip), crates.io publishing via trusted publishing (OIDC), a `wt switch` picker correctness fix after a deleted-CWD recovery, and a statusline dev-server URL dim. See CHANGELOG.md for the full list. > _This was written by Claude Code on behalf of max_v0.69.1 |
||
|
Maximilian Roos
|
bb43011c8d |
fix(picker): cancel background commands when the picker exits (#3560)
## What `shell_exec` gains `cancel_background_commands()`: it latches a flag that stops background `Cmd::run` / `Cmd::pipe_into` before they spawn, and SIGTERMs the PIDs of those already running (tracked in a registry each capture-mode command joins for its lifetime). The picker calls it once, after skim releases the terminal and after the stashed-warning drain. Preview diffs pick up `--no-optional-locks`, matching what `wt list`'s `git status` already does: a preview reads a worktree the user may be working in, and can now be signalled mid-run. Cancellation covers both accept and abort, and only ever targets background threads — the foreground thread is the one cancelling, and goes on to run the switch itself. ## Why Accepting the picker abandoned its preview work rather than stopping it. `wt`'s exit ends the pool's threads but not the `git` children they spawned, so those children kept running, orphaned, computing diffs into an in-memory cache that no longer existed — churning disk on a repo the user had already left. Measured on a 5-worktree fixture whose `git diff` sleeps 15s, with a shell (not `wt`) as the PTY session leader, since `wt` as session leader SIGHUPs its own children on exit and hides the effect entirely: | | children alive at t+0 / +1 / +3 / +6s after `wt` exits | | --- | --- | | without cancellation | 12 / 12 / 12 / 12 | | with cancellation | 0 / 0 / 0 / 0 | Single-variable control: same build, same fixture, cancellation gated off. Accept latency is unchanged (0.13s). ## Why a latch, not just a sweep A one-shot sweep over live PIDs isn't enough on its own. A task that has already cleared its caller's supersede check and parked on `CMD_SEMAPHORE` holds no PID for the sweep to find, and spawns the moment a permit frees — the very permits the sweep just freed by signalling everything holding one. Capping concurrency at 2 to force a queue reproduces it: sweep-only still leaves survivors, the latch reaches 0. For the same reason a freshly spawned child re-reads the flag as it registers, so a child spawned into the sweep's window escapes neither. This also replaced a first attempt that bumped the preview orchestrator's spawn generation. That stops *queued* tasks, but those tasks had already passed the generation check before parking on the semaphore, so it measured no better than the sweep alone. One mechanism in `shell_exec` covers all three states — queued, parked, running — so the orchestrator is untouched. ## Notes - **`alt-x` removals are exempt.** A removal is dispatched to its own thread so the picker stays live, so pressing Enter straight after can leave a `git worktree remove` in flight when the sweep fires. Its *result* is discardable; its *effects* are not, and a signal between the worktree remove and the branch delete would strand the user half-removed. `shell_exec::uninterruptible` exempts a thread from both halves — the sweep skips its PIDs, and the latch doesn't refuse the calls it makes afterwards, since a removal is several git calls rather than one. The picker routes every removal dispatch through one `spawn_removal` helper that applies the exemption, so it's carried by the spawn path itself rather than remembered at each call site. - **SIGTERM, not SIGKILL**, so git's lockfile handlers run rather than stranding an `index.lock` in a worktree the user is about to work in. - **Cancel is ordered after `drain_stashed_warnings`.** A `--prs` forge call killed mid-flight fails like any other and stashes that failure as a warning; cancelling first would print a spurious "couldn't fetch PRs" to the user. - **`Cmd::run`'s plain branch now spawns explicitly** instead of calling `cmd.output()`, whose stdio defaults it reproduces exactly — `output()` hands back only the finished result, never the running child. - **Windows** gets the latch but not the signal; a command already running there still finishes. Bounding those would take a job object. - **Tests.** The cancelled paths (both refusals and the mid-flight signal) are covered by `tests/cancel_background.rs`, deliberately its own test binary: cancellation latches process-wide state and signals every background PID in the process, so beside other tests it takes them out — `TestRepo`'s helpers drive git through the same `Cmd` path, and this is a real failure, not a theoretical one. Alone in its process it has nothing to collide with, and the test is deterministic (a file marker for readiness, not a sleep). An earlier revision of this description claimed `codecov/patch` contradicted its own line data. That was wrong — a mis-read of the API on my part, and the check was right. Local `cargo llvm-cov` had been failing to build `skim` (E0554), so I'd taken the API as a substitute for measuring. The build failure was a stale local tool: cargo-llvm-cov ≥ 0.7.0 instruments only workspace crates instead of the whole dependency graph, so on CI's pinned 0.8.7 `skim` never sees the `cfg(coverage)` that trips its nightly feature gate. With that upgraded, local coverage reproduces codecov's four missed lines exactly. Three were in `test_background_command_registers_while_running`, now removed — its poll loop's body only ran when the spawned thread hadn't registered yet. Coverage is the lesser reason: the test polled a process-global registry for non-emptiness, so under the shared-process runner the coverage job uses it could be satisfied by another test's PID and pass without its own command ever registering. `tests/cancel_background.rs` pins that property correctly, and more strongly — the sweep reaches a running command only if it registered. Three lines are left uncovered, knowingly. One is the spawn-race re-check, which by construction only fires on a race that can't be scheduled deterministically — covering it would need a scheduling hook in library code, which the repo's "no test code in library code" rule rules out. The other two are pre-existing: the `spawn_removal` refactor re-indents the dispatch closures, which codecov counts as new patch lines, pulling in the morph-failure backstop (the `warn` and `revert_morph` calls). That backstop only fires when a file appears in the TOCTOU window between the removal's safety check and the rename, so it can't be deterministically tested either. If `codecov/patch` reads red, this is why — the structural exemption was judged worth more than the metric. - **PID reuse.** Between the kernel reaping a child and the guard's `Drop` removing its PID, a freed PID is briefly still listed. Inherent to signalling by PID — the reap and the deregistration aren't one operation — and deregistering before the wait isn't a fix but a removal, since the wait *is* the command's lifetime. Documented on `BackgroundPid` rather than mitigated. > _This was written by Claude Code on behalf of Maximilian Roos_ --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Maximilian Roos
|
f5d99d4fe5 |
fix(step): refuse to commit unresolved conflicts; one gutter symbol for every operation (#3579)
Two follow-ups from #3558, which stopped `wt merge` and `wt step rebase` from running out of a half-finished operation. Probing the sibling commands for the same root cause found one that was worse, and the symbol work is what that PR's detection change made possible. ## `wt step squash` committed conflict markers Mid-merge, invoked directly, it didn't refuse. It generated a commit message for the unresolved markers and committed them: ```console $ git merge side CONFLICT (content): Merge conflict in f $ wt step squash --yes ◎ Generating commit message and committing changes... (1 file, +6, no squashing needed) Merge branch 'side' This resolves a merge conflict between main and side branches. ✓ Committed changes @ e6262c6 $ git show HEAD:f <<<<<<< HEAD main ||||||| 56e6eb3 base ======= side >>>>>>> side ``` `MERGE_HEAD` is gone and the working tree is clean, so the broken merge reads as complete. `wt merge` was never exposed — its own gate stops it before it reaches squash — so this was the direct-invocation path only. ## The index is what knows The obvious fix is the gate #3558 added, and it is not sufficient. The hazard is narrower than "an operation is open", and also wider. `git add -A` collapses an unmerged path's three index stages into one entry. That resolves the conflict as far as the index is concerned, while `<<<<<<<` is still on disk — and it takes with it git's own refusal to commit an unmerged index, which is what would otherwise have stopped this. So the exposure is exactly the commands that stage on the user's behalf, and it does not need an operation to be open at all: ```console $ git stash pop CONFLICT (content): Merge conflict in f $ ls .git/MERGE_HEAD ls: .git/MERGE_HEAD: No such file or directory $ wt step commit --yes ✓ Committed changes @ 1f5387c # markers and all ``` A conflicted `git stash pop` leaves unmerged paths with no state file written, so no reading of `.git/` can see it. `WorkingTree::ensure_no_unmerged_paths` reads the index instead — `git diff --diff-filter=U`, the same question `git commit` asks — and both staging paths call it before staging: ```console $ wt step commit ✗ Cannot commit: 1 path with unresolved conflicts ┃ f ``` The paths are worth carrying where the operation refusal carried nothing: they are the one thing the user needs and git isn't being asked. `wt step squash` additionally takes the operation gate, ahead of its branch check, so mid-rebase it names the open rebase rather than blaming the detached HEAD and offering `git switch <branch>` — the one command that throws the rebase away, which is the same wrong remedy #3558 removed from `wt merge`. Both guards run before the pre-commit hooks and the LLM call. Neither is worth running for a commit that can't happen, and a refused commit runs no project commands — checked with a `pre-commit = "touch HOOK_RAN"` project config that never fires. `wt step commit --dry-run` is deliberately not gated. It mutates nothing, and guarding it displaced `test_step_commit_dry_run_propagates_git_add_failure`, which pins a distinct error path; a tested behavior is worth more than cosmetic parity. ## One symbol for every operation The Status column had `⤴` for rebase and `⤵` for merge, and nothing for the other three states git can leave open. A worktree stopped mid-cherry-pick, mid-revert, or mid-bisect rendered as idle — including the case #3558 closed, a multi-commit cherry-pick whose stop was resolved with `git commit`, which leaves a clean tree, no `CHERRY_PICK_HEAD`, and only the queued sequencer to say anything is wrong. Three more glyphs was the obvious fix and the wrong one. What the reader does about any of the five is identical: run `git status`, then finish or abort it. Splitting the column across a glyph per operation asked them to distinguish states that lead to the same next step, and the split is what left the other three invisible. So they collapse to one: ```console $ wt list Branch Status … Message @ main ↻^ … resolved by hand ``` `git status` names which operation it is, in git's own words — the same division of labor as the refusal message. `--format=json` keeps the identity the symbol drops, so a consumer that needs it still has it: `operation_state` gains `cherry_pick`, `revert`, and `bisect` alongside `rebase` and `merge`. That retires `ActiveGitOperation`, which existed only to re-encode `InProgressOperation` down to the two states the gutter knew. `WorktreeData.git_operation` is now `Option<Option<InProgressOperation>>` — outer `None` is "not loaded" — matching its neighbour `has_working_tree_conflicts`. `GitOperationTask` also stops swallowing errors: it reports a failed probe through the same `ctx.error` channel every other task uses, rather than reporting "no operation" for a probe that didn't answer. ## Verification Three integration tests, each asserting HEAD is unmoved rather than only matching the message: - `test_step_squash_refuses_mid_merge` — the case that committed markers. - `test_step_commit_refuses_unmerged_paths` — driven from a conflicted `git stash pop`, so it can only pass through the index read; the operation check cannot see that state. - `test_list_shows_symbol_for_bisect` — bisect because it is the only operation that leaves HEAD on the branch and the tree clean, so nothing else in the Status cell stands in for it. Snapshots pin both the symbol and `"operation_state": "bisect"`. Confirmed by hand against real repos: mid-merge, mid-rebase, and the conflicted-stash-pop state all refuse; a mid-merge commit whose conflicts *are* resolved still succeeds, as does a clean squash; a queued cherry-pick and a stopped revert both render `↻` and name themselves in JSON. Full gate green (4500/4500 tests, lints, fmt, doc sync), plus `cargo test --features shell-integration-tests` (2148/2148) and `cargo clippy --all-targets --features shell-integration-tests`, which the gate doesn't compile. > _This was written by Claude Code on behalf of Maximilian_ --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Maximilian Roos
|
a07cf60be9 |
docs(claude): stop coverage from vetoing a better design (#3580)
## The failure this fixes A session working on the picker found a structural improvement: routing both removal dispatches through a `spawn_removal` helper, so the uninterruptible-cancellation exemption lives in one place instead of being remembered at each spawn site. It declined to make the change, because the helper re-indents the morph closure's body and pulls two pre-existing uncovered lines (a failure-path warn and a `revert_morph` call) into the patch. Projected `codecov/patch`: ~97.3% against an `auto` target of ~97.8%. Red. The improvement was shelved. The section it was reading said "NEVER merge a PR with failing `codecov/patch` without explicit user approval," then "on failure, investigate and fix the gap," then "if you believe it's a false positive, ask." Every route treats a red patch as a defect in the change. The cheapest way to satisfy all three is to not make the change. ## What changed The Coverage section now separates the two decisions it was conflating. The check gates the merge; it never gates the design. A predicted red patch is not a reason to shelve or water down an improvement, and neither the code nor the tests get contorted to move the number. The merge rule is unchanged: still never merge red without approval. What is new is the route through it when the gap isn't real (misses that predate the change, or a path with no deterministic trigger): push the change and ask, handing over which lines, why they can't be covered, and what the patch percentage comes to. Two smaller corrections ride along: - "Remove unused code" to green the number now excludes a rarely-reached backstop that's load-bearing. The picker lines in question guard a TOCTOU window during rename-based removal, and the repo's Data Safety rules would rather keep them. - `tests/CLAUDE.md`'s note on rename false positives now covers the mechanism that caused this. Codecov counts any line the diff relocates as a patch line, re-indentation included, not just a `git mv`. The `spawn_removal` refactor itself is not in this PR: it touches picker code mid-flight on #3560. > _This was written by Claude Code on behalf of @max-sixty_ Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Maximilian Roos
|
edcfe5fe0c |
fix: honour -C in the statusline and in every supplied path (#3567)
`-C` sets the repository discovery path but never chdir's the process, so anything reading `std::env::current_dir()` silently ignores it. Two places did. ## `wt list statusline` described the wrong worktree `wt -C /path/to/other/worktree list statusline` printed the statusline for the *cwd's* worktree, and from a directory outside any repo it printed nothing at all. Both formats now resolve their worktree through `Repository::current_worktree()`, which anchors to the discovery path. That accessor already exists for this bug class (its docstring cites #2625), so this is routing the statusline onto the canonical path rather than adding a new one. Details worth knowing while reading the diff: - `--format=json` was mostly right already. It picked its worktree via `current_worktree()` and only its "are we in a worktree" gate read the cwd, so it misbehaved just when the process cwd sat outside a repo (printed `[]`). That gate moves to `current_worktree()` and the `cwd` binding is gone. - `git_status_segments` now takes a `WorkingTree` instead of `(&Repository, &Path)`. That also settles a split inside it: the worktree lookup used the cwd while the no-worktree fallback used `repo.current_worktree()`. - `--format=claude-code` is unchanged where it matters. The directory Claude Code sends on stdin still wins, since that names the session's directory rather than wt's. With no stdin it falls back to the same worktree as the other formats, so it honours `-C` too. Four integration tests. Three run from the main worktree with `-C` pointed at a `feature` worktree, one per format; the existing statusline tests all set the child's cwd, which is the route that already worked. The fourth pins the claude-code split: when stdin names a directory in a *different* repository, the worktree comes from stdin while `list_worktrees` comes from wt's discovery path, so nothing matches and only the branch is reported. That fallback previously had no test, which is what `codecov/patch` caught on the first push. Discovering the `Repository` from the stdin directory instead would remove that split, but it would miss the `prewarm` cache (keyed on the base path) that this prompt-redraw hot path depends on, so the split stays and is now asserted rather than incidental. ## Supplied paths resolved from the shell, not from `-C` `wt switch ../repo.feature` and `wt remove ../repo.feature` joined the argument onto the process cwd. With `-C` in play that split the invocation in two — wt chose the repository, the shell chose the path — and the combination resolved to nothing, so `switch` reported "No branch named ../repo.feature". `--config`, `WORKTRUNK_CONFIG_PATH`, `WORKTRUNK_SYSTEM_CONFIG_PATH`, and the trace file of `wt config state logs profile` name a file the same way and had the same gap: `wt -C repo --config mycfg.toml config show` reported "Config file not found" for a file sitting in `repo/`. Git resolves the paths in its command line against its own `-C`, because it chdir's there before doing anything else. wt's `-C` sets a discovery path instead, so `resolve_input_path` joins onto that — one resolution point for all five, so they cannot drift apart. It returns the path untouched when `-C` was not given, rather than joining `.` onto it: the process cwd already resolves those, and the join would surface as a stray `./` in output. `Path::join` leaves an absolute path alone, which drops an `is_absolute` branch and, in `resolve.rs`, a fallible `current_dir()` call. Three neighbours are deliberately outside the rule, and the docstring says why: - Paths wt derives itself — a worktree root from `git worktree list`, an XDG config directory — arrive absolute. - `WORKTRUNK_PROJECT_CONFIG_PATH` resolves from the worktree root, its documented base, because the project config is per-worktree. - `WORKTRUNK_BIN` and `XDG_CONFIG_DIRS` are never opened by wt: the first is expanded later by the generated shell wrapper, and the XDG spec already requires the second to be absolute. Four integration tests, one per surface, each running from *outside* the repo with `-C` pointed into it — the neighbouring tests run from a cwd inside the repo, which is the route that works under either rule. All four fail against the old code: `switch` with "No branch named ../repo.feature-detached", `remove` by leaving the worktree standing, and the two config paths by not finding their file. The `set_base_path` docstring picks up the rule, so the next reader has one place to find it: `-C` is the base for the two things git takes from its chdir — the repository discovered, and every path the user names — while the process cwd stays the answer to where the user's shell physically is. ## Noticed, not touched `run_json` and `git_status_segments` duplicate the worktree-lookup-and-populate sequence (`list_worktrees` → find by root → `is_home` → `build_worktree_item` → `populate_item` with identical `CollectOptions`). Worth collapsing separately. > _This was written by Claude Code on behalf of max_ |
||
|
Maximilian Roos
|
f9cd38eb88 |
fix(shell): validate command names and tighten install/uninstall detection (#2864)
Two shell-integration correctness fixes plus an uninstall-scope
redesign.
**Command-name validation.** The shell-integration command name comes
from the user-typed `--cmd` flag, or `argv[0]` when `--cmd` is omitted.
A malformed value (an empty string, a leading `-`, or characters like
`;` or whitespace) renders into a broken shell rc line that the user
then has to find and fix. `validate_shell_command_name()` rejects empty,
leading-`-`, and non-`[A-Za-z0-9._-]` names at the CLI entry points, so
a bad value produces a clear error up front instead of a silently broken
config file. This is input hygiene on a value the user already controls,
not a security boundary.
**Noncanonical-line detection on install.** Install recognized only its
exact current canonical line, so a manually-added or older-form
integration line (e.g. `eval "$(wt config shell init zsh)"`) was not
seen as already-present and a duplicate was appended on the next
`install`. It now detects those forms and reports already-configured.
**Uninstall scans every worktrunk-managed file, regardless of cmd.**
Previously `uninstall` located Fish/Nushell wrapper files by name
(`{cmd}.fish` / `{cmd}.nu`), so removing integration installed under an
alternate binary name needed a matching `--cmd`. That symmetry leaked an
implementation detail: uninstall already has a content marker to
recognize worktrunk wrappers regardless of binary name. It now scans the
wrapper directories (`~/.config/fish/functions`, `conf.d`; the nushell
candidates' `vendor/autoload`) and admits every file whose content
matches the cmd-agnostic marker `# worktrunk shell integration for
<shell>` (always emitted by the wrapper templates). A headerless file
(the legacy `conf.d/{cmd}.fish`, which held nothing but the init line)
qualifies only when every non-blank, non-comment line is an integration
line, so a user's own file that runs or merely mentions `wt config shell
init` amid other code survives the scan. Fish completion files carry
their own `# worktrunk completions for` header and are scanned the same
way, so a completion whose wrapper is already gone is still cleaned up.
For Bash/Zsh/PowerShell (line-based),
`is_shell_integration_line_for_uninstall_any_cmd` reads the binary name
off the line rather than pattern-matching it. `config shell init` is a
fixed literal, so the name is the run of command-name characters ending
at it, held to the same `validate_shell_command_name` rule that governs
what worktrunk writes into shell code. The execution-context check that
pairs with it is a line-level property, so it lifts out of the
per-position loop it used to sit in, which is what let both cmd-agnostic
detectors drop their regexes. Since the result asks only whether a line
is worktrunk's, not which install owns it, uninstall also removes
hand-written `git wt config shell init` lines, and it cleans every
matching profile file rather than the first (both PowerShell profiles on
Windows). All detection reads only the code portion of a line: a
trailing `#` comment can mention an integration line without running it,
so uninstall does not delete an unrelated `eval`/`source` line over a
comment, and install does not treat such a mention as
already-configured. The cmd-specific permissive detector lost its last
caller in this cutover and is deleted.
The `--cmd` flag is removed from `wt config shell uninstall`; `install`
keeps it (installing under an alternate name is still a deliberate
per-cmd act). The FAQ's "What can Worktrunk delete?" inventory documents
the widened uninstall surface.
Covered by new integration tests: custom-cmd install + cmd-less
uninstall round-trips for zsh/fish/nushell (verifying scan-all removes
the custom-cmd integration, a hand-written `git wt` line, a stale second
wrapper, and an orphaned completion), a PowerShell uninstall round-trip
on the old pre-`Out-String` line, malformed-name rejection at the CLI
edge (`--cmd` and `argv[0]`), and the older-line dedup case. Unit tests
pin the deletion criterion: worktrunk's own wrappers and the headerless
legacy init file match; a file that mentions the integration, or runs it
amid other code, does not.
> _This was written by Claude Code on behalf of Maximilian Roos_
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Worktrunk Bot <w@worktrunk.dev>
Co-authored-by: worktrunk-bot <254187624+worktrunk-bot@users.noreply.github.com>
|
||
|
Maximilian Roos
|
4549715af1 |
docs(claude-code): link the statusline segment details instead of restating them (#3576)
The `## Statusline` section of `claude-code.md` paraphrased three facts that the `wt list statusline` reference already owns: | Fact | `claude-code.md` said | `src/cli/list.rs` says | |---|---|---| | Pace maths | "1.4× the pace that would exactly fill that window, coloured by how much of it would be spent locked out at the cap" | "2.9× the pace that would exactly fill that window… colour deepens with severity as the forecast lockout grows" | | Link degradation | "clickable links where the terminal supports them, plain text where it doesn't" | "Both links are OSC 8, which a terminal that doesn't support them discards" | | CI fetch latency | "runs it in the background… 1–2 second CI fetch invisible" | "reach the network for a second or two, so it fits a statusline the host renders in the background" | #3568 removed the near-verbatim copies from this section but left these paraphrases behind, which is arguably the worse state: two wordings of one fact drift apart independently, and a reader can't tell whether they're the same claim or two different ones. ## What stays The cut isn't to zero. The page shows an example line, so it needs enough gloss for a reader to parse the line in front of them — a bare pointer would make the section a stub. It keeps one sentence naming what the stdin JSON contributes, with "how the links behave" folded into the pointer that was already there. The latency clause also stays, though it is the third duplicated fact. Without it the opening paragraph only restates the command name, and it is the one "why" that justifies the `settings.json` block below it. ## Side effect This leaves the `OSC 8` wording in `src/cli/list.rs` as the single home for the link behaviour. A precise term earns its place in an exhaustive `--help` reference and grated on an end-user integration page — so the jargon was really a symptom of the fact living in two places. Docs-only. Mirrors regenerated by `test_docs_are_in_sync`; `zola build` clean (14 pages, anchors resolve). > _This was written by Claude Code on behalf of Maximilian Roos_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Maximilian Roos
|
11a1498fa1 |
docs(list): render wt list statusline's help on the docs site (#3568)
`wt list statusline`'s `after_long_help` documents the three output formats, the Claude Code stdin JSON contract, and the pace segment, but `wt list`'s help had no `<!-- subdoc: statusline -->` placeholder, so none of it reached `docs/content/list.md` or the skill reference. It was terminal-only. Adding the placeholder pulls it in as a `wt list statusline` section under `# Subcommands`, matching how `wt step` and `wt config` expose theirs. ## What reading it on the web surfaced The help text needed edits once it rendered as a page rather than a block below an Options list. A context-blind agent was given the two rendered pages and asked to answer setup questions from them alone; three of its snags were real. **The format lists were stale and used private names.** They read `branch status ±working commits upstream ci url`, while the Columns table higher up the same page calls those `HEAD±`, `main↕`, `Remote⇅`. They also omitted `main…±`, which `format_statusline_segments` has emitted since that column became a default. The lists now use the column names and include it, and `claude-code` is stated as a delta on `table` rather than repeating it. **The formats read as a fixed layout.** The example line on the Claude Code page has nine segments against an eleven-name format string, with no explanation. Three rules were in the code and in no doc: empty cells are omitted, `claude-code` drops `branch` when `dir` already ends in `.<branch>` (`filter_redundant_branch`), and an overlong line drops whole cells worst-priority-first (`fit_to_width`). All three are now stated. **The latency caveat lived only on the Claude Code page.** A reader of the command's own docs had no way to learn it reaches the network. It moves to the reference. That exposed a contradiction with the definition, "Single-line status for shell prompts", against a caveat saying it is too slow for a synchronous prompt — so the definition becomes "Single-line status for the current worktree". This is the one user-visible string change here; it lands in `wt list --help` and the three help snapshots. ## Deduplication with the Claude Code page The pace paragraph and the OSC 8 paragraph were near-verbatim on both pages, and would have rendered twice on the site. `claude-code.md` keeps what is Claude Code-side (install, demo, the example line, and a plain note that the links degrade to unclickable text where the terminal lacks support) and links to the reference for the rest. ## Follow-ups folded in The module docstring at `src/commands/statusline.rs:4` carried `±working commits upstream`, the last occurrence in the tree of the labels this branch retired, and opened "Statusline output for shell prompts" — the framing the definition dropped. Both now match the help text. ## Not done An audit of every `after_long_help` in `src/cli/` found 46 that never reach a docs page. Most are editorial calls rather than oversights: `wt config create` alone would embed ~450 lines of example TOML into a page that already covers that ground by hand. The one that looks like a plain oversight is `wt step rebase` / `wt step push`, the only two of twelve step operations without a marker, and the only two the `## Operations` list leaves unlinked. Covering them needs their openers rewritten first, since both currently restate their definition. Left for a follow-up. Verified with `wt hook pre-merge --yes` (4499 tests) and a `zola build`, which checks internal anchors. > _This was written by Claude Code on behalf of Maximilian Roos_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Maximilian Roos
|
84cbb0489e |
fix(step): refuse to rebase or merge from a worktree mid-operation (#3558)
## The bug With a rebase in progress (a conflicted stop, or a killed `git`), `wt step rebase main` reported success over a conflicted tree: ```console $ git rebase main # stops on a conflict; HEAD detached mid-replay $ wt step rebase main ○ Already up to date with main $ echo $? 0 ``` `handle_rebase` asked `is_rebased_onto` first. Mid-rebase, HEAD sits on a linear extension of the target, so that returns true and the function returns `UpToDate` before anything consults `worktree_state`. `wt merge` from the same state failed differently but no better: ```console ✗ Cannot merge: not on a branch (detached HEAD) ↳ To switch to a branch, run git switch <branch> ``` The hint names the one command that throws the rebase away instead of finishing it. ## The fix Both commit-replaying commands now check for an open operation before doing anything else. `wt merge` runs the check ahead of its branch check, so the open operation is what gets named rather than the detached HEAD it causes. ```console $ wt step rebase main ✗ Cannot rebase: a git operation is already in progress ``` The gate covers every state detection reports, not just rebase. Measured on the others beforehand: a rebase started mid-bisect ran and stacked a second operation on the first, and one started mid-merge or mid-cherry-pick died inside git's autostash (`Cannot save the current index state`, `f: needs merge`). None told the user what to do next. ## Why it prescribes no remedy An earlier draft of this branch carried a per-operation table of `--continue`/`--abort` hints. It was wrong on first contact with the long tail: `git am` borrows the `rebase-apply` directory, so an open am session was reported as a rebase and pointed at `git rebase --continue`, which git refuses outright: ```console $ git rebase --continue fatal: It looks like 'git am' is in progress. Cannot rebase. ``` Adding an `Am` arm would have treated the enumeration as the fixable part. `git status` already answers this better than the table did, in git's own words and translations, for states worktrunk has no variant for: ```console $ git status interactive rebase in progress; onto b162044 You are currently rebasing branch 'feat' on 'b162044'. (fix conflicts and then run "git rebase --continue") (use "git rebase --skip" to skip this patch) (use "git rebase --abort" to check out the original branch) ``` It names the operation, the branch, the progress, and every way out including `--skip`, which the table never offered. So the table is gone rather than extended, and the refusal is a single line: it says what is blocked and why, and leaves the rest to the command every git user reaches for next. Detection still returns a structured `InProgressOperation` rather than a display string, but now purely as detection: the only caller that reads a variant is the one classifying a rebase worktrunk itself just started. The neighbouring `RebaseConflict` error took the same treatment. It forwards git's stderr in the gutter when it has it, and otherwise substituted two hint lines of its own: ```console ↳ To continue after resolving conflicts, run git rebase --continue ↳ To abort, run git rebase --abort ``` That is the operation table again in miniature — one operation's remedies, minus `--skip` — and the one path that reaches it is the safety check for a rebase git *reported as finished*, where worktrunk knows least about what is actually open. It now prints its title, plus git's own words when git said any. ## One detector Two places probed the same files for the same answer: `Repository::worktree_state` for the gate, and `WorkingTree::is_rebasing`/`is_merging` for the `wt list` gutter symbols. They are now one method, `WorkingTree::operation_in_progress`, which `Repository::operation_in_progress` delegates to — the rename also retires a name that collided with `wt list`'s unrelated `WorktreeState`. Detection now runs in the order `git status` consults the state files, which is a change from the old `wt list` path: it checked rebase before merge. Nothing can reach the difference — no rebase backend writes `MERGE_HEAD`, checked against all three — but matching git's order is one less thing to reason about. `wt list` maps the operations without a gutter symbol (cherry-pick, revert, bisect) to `None`, so its output is unchanged. ## The queued sequencer, now closed Having one detector is what made the last gap worth closing. `git cherry-pick A B` that stops on A writes `CHERRY_PICK_HEAD`; resolving that stop with `git commit` instead of `git cherry-pick --continue` removes the file and leaves B queued: ```console $ git status On branch main Cherry-pick currently in progress. (run "git cherry-pick --continue" to continue) $ ls .git/CHERRY_PICK_HEAD ls: .git/CHERRY_PICK_HEAD: No such file or directory $ cat .git/sequencer/todo pick 1f07533 side1 pick 6b32540 side2 ``` Git reads that same file to keep calling the sequence in progress, so detection reads it too: the first instruction word, `pick` or `revert`, exactly as git's own `sequencer_get_last_command` does. The reason this waited for its own change is the risk of refusing a `wt merge` the user can't un-refuse, so the lifecycle is measured rather than assumed. The directory is gone once the sequence finishes, and gone after `--quit` or `--abort`; a single-commit cherry-pick never creates one; a rebase keeps its todo elsewhere, under `rebase-merge/`. An empty or unrecognized todo reports nothing, so the failure direction is the old behavior rather than a refusal with no way out. ## Verification The repro above, plus the merge, am, cherry-pick, revert, and bisect states, checked by hand against real repos: all five refuse, including am, which is now correct precisely because nothing here claims to know what am needs. Three integration tests drive the real binary from a genuinely stopped operation (`test_step_rebase_refuses_mid_rebase`, `test_merge_refuses_mid_rebase`, `test_merge_refuses_mid_merge`). `test_merge_refuses_mid_merge` is what holds the broadened scope: a conflicted merge keeps HEAD on the branch, so it is the case the detached-HEAD check waves through. Narrowing the gate back to rebase-only turns it red, which I verified by making that edit and re-running. The sequencer case is driven end to end from a real stopped pick — `test_operation_in_progress_reads_the_queued_sequencer` commits the resolution by hand, asserts `CHERRY_PICK_HEAD` is gone, and still expects a cherry-pick, so it can only pass through the sequencer read. It then runs `git cherry-pick --quit` and expects the state to clear, which is the false-refusal half. Running the same sequence against the built binary refuses where it previously reported `○ Already up to date with main`. Confirmed unchanged: already-up-to-date, fast-forward, true-rebase, and rebase-conflict output; a plain detached HEAD still gets the `git switch` hint, which is the right remedy when no operation is open; a sibling worktree mid-rebase does not block a clean one; `wt list`'s gutter symbols. Full gate green (4494/4494 tests, lints, fmt), plus `cargo clippy --all-targets --features shell-integration-tests`, which the gate doesn't compile. ## Merged with main `main` gained #3539, which extracted the failed-rebase classification into `classify_rebase_failure`, and #3549, which adds `span_upstream` — both inside `handle_rebase`. The conflict was semantic as well as textual: #3539's `is_rebasing` check still read the old string API (`worktree_state()?.is_some_and(|s| s.starts_with("REBASING"))`), which this branch removes, so resolving the markers alone left a type error. The resolution keeps #3539's classification and reads the structured enum instead: ```rust let state = repo.operation_in_progress()?; let is_rebasing = matches!(state, Some(InProgressOperation::Rebase)); return Err(classify_rebase_failure(e, is_rebasing, &integration_target)); ``` All five of #3539's classification tests pass alongside the gate. > _This was written by Claude Code on behalf of Maximilian_ --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Maximilian Roos
|
7b741d0791 |
fix(release): stop double-zipping the SignPath upload artifact (#3566)
## Summary - `actions/upload-artifact` wraps every upload in its own GitHub storage zip unless `archive: false`. The uploaded file here is already a zip (`worktrunk-x86_64-pc-windows-msvc.zip`), so the default produced a zip-of-a-zip — SignPath treated the outer storage wrapper as "the artifact" and the configured `<pe-file path="wt.exe">` never matched anything inside it. - Root-caused this against the real v0.69.0 release run: the SignPath dashboard shows the failed request's unsigned artifact as `unsigned-windows-zip.zip` (16.8MB, matching GitHub's storage-wrapper name, not the real filename) with error `Expected path to match exactly 1 item, but found 0` for `wt.exe`. - `archive: false` uploads the file as-is (single-file only, which is what we have), so SignPath receives the real zip directly, one level shallower — matching the artifact configuration as originally written. - Also fixes the v0.69.0 CHANGELOG's SignPath entry, which read "Signed with a test certificate" — overclaiming, since the actual signing attempt on that release failed. Reworded to describe the pipeline's intent rather than a specific run's result. v0.69.0 shipped with an unsigned Windows binary as a result (signing failure was masked by the intentional `continue-on-error`, so the release itself succeeded — this is exactly the non-blocking behavior that was designed in). This fix should make the next release's signing attempt succeed for real. ## Test plan - [x] `actionlint .github/workflows/release.yaml` — no new warnings - [x] Root cause confirmed directly against the SignPath dashboard's error details and artifact tab for the failed v0.69.0 signing request - [x] Verified `archive: false` semantics against `actions/upload-artifact@v7`'s own `action.yml` (single-file upload, uploaded as-is) > _This was written by Claude Code on behalf of Max_ |
||
|
Maximilian Roos
|
f87e678aa1 |
fix(switch): trim redundant Repository rebuilds on the accept path (#3557)
## Summary Follow-up to #3544's `wt switch` review, from investigating why the accept path re-forks `git config --list -z` and rebuilds `Repository` more than necessary. - Skip the destination-rooted `Repository::at()` in `spawn_switch_background_hooks` when the approved hook plan is empty (the common no-project-hooks case) — `HookAnnouncer::flush()` is already a no-op there, so this changes no behavior, only cost. - Fix the picker's `is_recovered` accept-path arm, which reused the startup-time `Repository` unconditionally. An in-picker alt-x/alt-r during a recovered session can mutate the worktree/branch inventory, and that arm never rebuilt to see it — the non-recovered arm already gets this via a fresh `Repository::current()`. Rebuild via `Repository::at` (mirrors the picker's own `rebuild_repo` idiom) instead of `Repository::current()`, which fails after a deleted-CWD recovery. - Replace a misleading comment ("reuse the recovered repo") with the actual freshness rationale. A fourth change — sharing the bulk config cache across same-process `Repository` instances by `git_common_dir` — was implemented and then reverted: the pre-merge gate's `test_primary_remote_honours_checkout_default_remote` caught a real staleness bug (a config mutation between two `Repository::at()` calls, e.g. from a switch hook, would go unobserved by a cache hit with no invalidation path). Measured idle-repo cost of the remaining duplicated config forks is small (~5-10ms each), and the risk of a bespoke process-wide cache with no write-invalidation wasn't worth it. ## Test plan - [x] `cargo run -- hook pre-merge --yes` (full test + lint suite): 4483 tests passed - [x] `cargo clippy --all-targets --features shell-integration-tests -- -D warnings`: clean - [x] Targeted tests: `git::repository::`, `picker::`, `worktree::switch::`, `hook_plan::` > _This was written by Claude Code on behalf of Maximilian Roos_ --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Maximilian Roos
|
481125801f |
ci: publish to crates.io via trusted publishing (#3564)
## What `publish-cargo` now mints its crates.io credential per run through `rust-lang/crates-io-auth-action` (GitHub Actions OIDC) instead of reading the `CARGO_REGISTRY_TOKEN` environment secret. The job gains `id-token: write` for the OIDC exchange and `contents: read` for checkout, narrowing it from the workflow-level `contents: write`. The token lives for about 30 minutes and the action's post step revokes it, so no long-lived publish credential exists anywhere. ## Why The stored token expires on a schedule, and each expiry is a silent trap: nothing breaks until the next release tag, which is exactly when you don't want to discover it. ## Prerequisite, already in place A Trusted Publisher is configured for `worktrunk` on crates.io — repository `max-sixty/worktrunk`, workflow `release.yaml`, environment `release`. It had to land before this merge, since otherwise `publish-cargo` would fail at the auth step on the next release tag. `CARGO_REGISTRY_TOKEN` can be deleted from the `release` environment once a release has gone out this way. `AUR_SSH_PRIVATE_KEY` stays. > _This was written by Claude Code on behalf of max_ |
||
|
Maximilian Roos
|
166e1190ba |
refactor(perf): canonicalize wt-perf prune-fixture layering + completion config (#3548)
## What Three behavior-preserving canonicalizations of the `wt-perf` benchmark fixtures, from a design pass on "why does prune need its own generator, and can the fixtures consolidate?" 1. **Share the prune-population layer.** `create_prune_repo_at` (synthetic) and `create_prune_real_repo_at` (rust-scale) both layered the same two populations onto their base repo — `add_diverged_backdrop` (the scanned-but-never-removed backdrop) + `add_squash_merged` (the removable candidates). Extracted into `add_prune_populations`, so the base repo (synthetic `create_repo_at` vs. rust clone) is now the *only* thing the two fixtures differ in, spelled out once instead of twice. 2. **Canonicalize `completion.rs` onto `RepoConfig::branches`.** Its two inline `RepoConfig` literals were exactly `RepoConfig::branches(50, 0)` (one with `worktrees` overridden), so they now use the canonical preset via struct-update instead of respelling all seven fields. 3. **Document the fixture → bench mapping.** `benches/CLAUDE.md` listed the `wt-perf setup` handles in one section and the bench groups in another with nothing connecting them, so a bench and its fixture (`full` and `mixed`) read as overlapping names for the same thing. Added a mapping table and the rule behind it. ## Why this is the whole safe consolidation The design question was whether prune could drop its bespoke generator for a "standard one with different params" — ideally one diverse repo serving prune *and* the other benches. The answer is that prune's generator is **already** a thin composition (`create_repo_at` + two additive layers), and it can't fold into the shared `mixed`/`full` fixture without breaking three prune-specific invariants: a known/cleanly-separated candidate count (the destructive `live` path re-creates exactly the consumed candidates), untracked-only dirt (the `git reset --mixed` index-heal depends on it — `mixed`'s staged-dirt states violate it), and a provably-unintegrated backdrop. And benchmark fixtures optimize for *attribution*, not realism: the uniform single-axis fixtures (`worktree_scaling`, etc.) exist precisely because the diverse `full` fixture can't localize a regression, so diversifying them would lose that. On the `full`/`mixed` naming specifically: they can't be canonicalized to one name, because fixtures and benches are **many-to-one** — `RepoConfig::typical` alone backs five bench groups (`skeleton`, `worktree_scaling`, `first_output`, `picker_preview`, `remove_e2e`), two of which sit in the same file measuring different things. `full`/`mixed` only looks 1:1 by coincidence. Renaming also isn't free: `.github/scripts/criterion-to-jsonl.py` keys each time-series row by the criterion output path (`<group>/<id>`) for the daily gist append, so a rename orphans that series. Documented rather than renamed. ## Proposed follow-up (not in this PR) The one remaining real duplication is two *implementations* of "two-sided-diverged population forked across history depth": `add_diverged_backdrop` (plumbing-based, scales to rust) vs. the diverged branch states inside `create_mixed_repo` (checkout-based, synthetic-only). They can't naively merge — the checkout path would make `prune-real` take minutes per branch — but a shared plumbing primitive could back both. That rewrites a carefully-tuned fixture feeding the `full` bench with **no shape-assertion test to catch drift**, so I'd land a fixture-shape test first (count refs by state + assert integration status). Happy to do it if wanted. ## Verification fmt `--check` clean; `clippy -p wt-perf --all-targets` and `clippy --bench completion` clean; `pre-commit` clean on the doc; `cargo test -p wt-perf` passes (incl. the prune-fixture tests `squash_merged_fixture_is_content_integrated` / `prune_fixture_state_classifies_lifecycle`, which exercise `create_prune_repo_at` → `add_prune_populations`); all benches build. Table contents verified against the code by grep. > _This was written by Claude Code on behalf of Maximilian Roos_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Maximilian Roos
|
f3e5c82604 |
feat(statusline): dim the dev-server URL until its port answers (#3561)
Follow-ups to #3550. The dev-server URL in the statusline dims until something answers on its port, matching the `wt list` cell it was already copying in every other respect. ``` ~/w/worktrunk.feature ↕|🤖 ↑2 ↓1 #3550 :17913 server up ~/w/worktrunk ⊂| ↑2 ↓1 #3550 :12107 server down (dim) ``` `url_active` was already collected on this path (the health check runs under the statusline's full-column plan), so the dim consumes something already paid for rather than adding a probe. ## The other half, and why it isn't here The follow-up list also carried "detect OSC 8 support and render accordingly", which is how `wt list` decides its URL cell: linked `:3000` when the terminal supports hyperlinks, the URL in full when it doesn't. I built that, and three review passes took it apart. Recording the path, because the conclusion is the interesting part: 1. The first version probed `stderr`, since a shell prompt captures stdout through command substitution, and forced links on for `--format=claude-code`. An adversarial pass showed the exception reintroduced the bug it was meant to fix: Claude Code re-emits OSC 8 to the terminal rather than drawing it, so Claude Code inside Apple Terminal got the link, and the URL collapsed to a bare `:3000` with its host inside an escape the terminal discarded. 2. Reading the environment alone fixed that and deleted the exception. Then a bug sweep measured what the plain-text fallback actually costs: unlinked, the cell grows from 5 columns to the whole URL, and the URL is the worst-priority segment, so `fit_to_width` drops it first. Against a long dev hostname the linked line kept the URL down to 39 columns and the unlinked one lost it below 82. At 80 columns in tmux the "fallback" showed nothing where the old code showed a clickable port. 3. Separating the two decisions fixed that (collapse to `:port` always, link only when the terminal renders it) but left the probe controlling nothing but escape bytes. At which point an outer-loop pass asked whether it should exist, and it shouldn't: - The [OSC 8 spec](https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda) guarantees a terminal implementing OSC parsing per ECMA-48 "is guaranteed not to suffer from compatibility issues … the target URI is silently ignored and the supposed-to-be-visible text is displayed, without artifacts." The named buggy set is VTE up to 0.48 (2018), Windows Terminal up to 0.9, Emacs term-mode, and screen with 700+ character URLs. The statusline has emitted unconditional OSC 8 to shell prompts since #199 in January, on that same reasoning. - `supports-hyperlinks` is an allowlist, so its dominant error is the false negative. xterm, foot, mintty, rio, contour and a configured tmux all render OSC 8 and none are named. The probe's certain cost is withdrawing a working link from those users, against a speculative and shrinking risk. - The escape-hatch argument I had for it was inert. Once the probe no longer changed any text, `FORCE_HYPERLINK=0` could not reproduce what the old hardcoded Claude Code gate did, which was print the URL in full and copyable during that regression window. So the answer to "shouldn't we detect?" is that `wt list` detects because there the answer changes what the reader gets: `estimate_url_width` reserves a column wide enough for the full URL, so an unlinked cell can print it. The statusline reserves nothing, so it has no second rendering to switch to. `format_url_cell` now says that, in place of a stale note claiming the statusline's stdout was a pipe "to its editor". ## Also here - `isolate_subprocess_env` scrubs `FORCE_HYPERLINK`. It stands alone: `wt list` probes with `on(stream)`, which is `(FORCE_HYPERLINK set || tty) && allowlist`, and tests pin `TERM=alacritty`, so a developer with `FORCE_HYPERLINK=1` exported flips the `wt list` table snapshots from full URL to linked `:port`. - The `table` and `claude-code` format lists in `wt list statusline --help` name the `url` segment, which they emit and never listed. - A `--format=claude-code` test pins where the URL segment lands among the directory, CI and model segments. ## Verification Full gate green (`cargo run -- hook pre-merge --yes`, 4486 tests). Beyond the suite, the built binary rendering a live and a dead port, and the drop threshold measured at six widths to confirm the segment behaves as before. ## Known, not addressed A `[list] url` with no port is permanently dim on both surfaces: `UrlStatusTask` only connects when a port parses, so `url_active` stays `None`, and the `== Some(true)` test reads "never checked" as "nothing listening". Pre-existing in `render.rs`, which this change doesn't touch. 🤖 Generated with [Claude Code](https://claude.com/claude-code) > _This was written by Claude Code on behalf of max_ --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Maximilian Roos
|
e2b9563701 |
docs: TODO deferred merge-stats split and squash-preview coverage (#3563)
## Summary Follow-ups from #3549 (the stale-local-ref fix, fixing #3519), recorded as inline TODOs rather than a separate tracking issue: - **`src/commands/worktree/push.rs`**: `MergeContext::prepare`'s `commit_count` mixes carried fast-forwarded upstream commits with the branch's own squash commit when the target was behind its upstream, so the merge success line ("Merged to main (N commits, ...)") overstates the branch's own contribution. Splitting it needs a carried-count threaded through `MergeContext` — deferred as cosmetic. - **`src/commands/step/squash.rs`**: `preview_squash` (backing `--dry-run`/`--show-prompt`) shares the upstream-measured base with `handle_squash`, but only the mutating path has a test asserting it (`test_step_squash_measures_against_upstream_when_local_main_stale`). A snapshot test pinning the preview output in the same stale topology would close this gap. No behavior changes — comments only. ## Test plan - [x] `cargo check` - [x] `cargo clippy --all-targets` - [x] `cargo fmt --check` 🤖 Generated with [Claude Code](https://claude.com/claude-code) > _This was written by Claude Code on behalf of Maximilian Roos_ Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Maximilian Roos
|
c1c70a7e39 |
docs(changelog): fold #3549 and #3539 into the 0.69.0 changelog (#3562)
> _This was written by Claude Code on behalf of max_v0.69.0 |
||
|
Maximilian Roos
|
7b2e0705a1 |
Release v0.69.0 (#3559)
Highlights: clickable CI and dev-server-URL statusline segments in Claude Code (#3550), `wt merge --no-rebase` accepting merge-shaped fast-forward histories (#3509), a faster and lower-CPU `wt switch` picker (#3544, #3534), and SignPath code signing for the Windows release binary (#3553). Full details in CHANGELOG.md. > _This was written by Claude Code on behalf of max_ |
||
|
Worktrunk Bot
|
784de4aacb |
skills(running-tend): nightly defers repo-wide CI breakage to tend-ci-fix (#3320)
## What Adds a "Repo-Wide CI Breakage" note to the nightly reference (`.claude/skills/running-tend/references/nightly-cleaner.md`): a failure that reproduces identically on `main` and every PR belongs to `tend-ci-fix`, which fires on any `ci`-workflow `failure` on `main`, and a non-required job failing is enough to trigger it. It does not fire on runs that end `cancelled`, so the nightly records the breakage in its summary rather than assuming the handoff lands. Also updates the `SKILL.md` reference index, which listed only "branch naming" for a file covering three topics. ## Why A nightly run shipped its sweep PR, then while polling that PR's CI diagnosed an unrelated repo-wide `code-coverage` break and started a second fix it did not finish, stranding the work on a pushed branch with no PR. Two workflows chasing the same repo-wide break duplicate effort and can produce conflicting PRs. Which workflow owns that break is not derivable from the nightly's own context, and it is documented nowhere else in the repo's skills (the only other mention of ci-fix is a label description). That is the whole of what this PR adds. ## What was cut, and why Earlier revisions carried a session-budget rule as well: the session has no room for a second deliverable, so ship one thing and stop. That rested on a 3600s harness cap. The cap has been 10800s since tend 0.1.9 and becomes 21000s once the pending tend release lands, so the claim does not hold at current durations, and its evidence was a single run. Removed. The routing advice also needed a correction rather than a restatement. `tend-ci-fix` gates on `conclusion == 'failure'` (`.github/workflows/tend-ci-fix.yaml:18`), so a `ci` run cancelled by rapid pushes never triggers it. Presenting the handoff as reliable would send a real breakage nowhere, so the note names the gap. ## Status of the breakage that prompted this Resolved independently: `cache-apt-pkgs-action` no longer appears anywhere under `.github/` on `main`, so the pin mismatch the nightly diagnosed is gone. The orphan branch `fix/ci-cache-apt-pkgs-pin-sha` is still on the remote and is now moot. 🤖 Generated by the tend review-runs workflow ([run](https://github.com/max-sixty/worktrunk/actions/runs/28361631224)), revised since. > _This was written by Claude Code on behalf of max_ --------- Co-authored-by: worktrunk-bot <254187624+worktrunk-bot@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: Maximilian Roos <m@maxroos.com> |
||
|
Maximilian Roos
|
9ecd7945e0 |
fix(merge): measure squash/rebase against the target's upstream, not a stale local ref (#3549)
Fixes #3519. ## The bug `wt merge` resolves its target to the **local** default-branch ref and squashes/rebases the span `merge-base(local-target, HEAD)..HEAD`. When the primary checkout's local `main` is behind `origin/main` **and** the branch descends from the newer `origin/main` tip (e.g. created with `--base origin/main`), that merge-base falls back at the stale local tip, so the span sweeps in every commit already on `origin/main`. The squash folds them into a single commit and the local fast-forward lands it — corrupting the primary checkout's `main` and, if that ref is later pushed, duplicating already-upstream content under new SHAs. Reproduced deterministically before fixing: a 1-commit feature off `origin/main`, with local `main` two commits behind, squashed "3 commits" into a new SHA on local `main` — matching the report. The same mis-measured span reaches every rewrite entry point: a standalone `wt step squash` folds the upstream commits into the *branch* (the reporter's 1-commit PR becoming 13), and `wt step rebase` replays them onto the stale ref when it fires. ## The fix: measure against the upstream; let the merge carry One local-only predicate (no fetch — worktrunk is local-first), `Repository::span_upstream`: the target's upstream, returned exactly when the branch's history extends past the local target ref into it — i.e. `merge-base(HEAD, upstream)` is not an ancestor of the local target. The rewrite pipeline responds by *measuring* there instead of guessing from the stale ref: - **`wt step squash`** (and the squash inside `wt merge`) computes its span, commit count, message, and `reset --soft` base against the upstream — only the branch's own commits fold, and the target ref is never touched. The `--dry-run`/`--show-prompt` previews use the same base. - **`wt step rebase`** (and the rebase inside `wt merge`) rebases *onto* the upstream, so a non-linear branch replays only its own commits instead of duplicating upstream ones onto the stale ref. In the plain stale topology it no-ops, as before. - **`wt merge`** announces the situation up front, then completes: the fast-forward carries local `main` through the already-fetched upstream commits by their real SHAs to the result — the same graph a fresh local `main` would have produced: ``` ○ Local main is 2 commits behind origin/main; the merge fast-forwards through them ◎ Squashing 2 commits into a single commit (2 files, +2)... ✓ Squashed @ 3f2a91c ✓ Merged to main (3 commits, 3 files, +3) ``` The one refusal left is forced by topology rather than chosen by policy: a target that has **diverged** from its upstream (its own commits *and* behind, with the branch based past it) can never fast-forward in any mode — reconciling the target's own commits is the user's call, so the merge stops before any rewrite or approval prompt: ``` ✗ Local main has diverged from origin/main — can't fast-forward to a branch based on origin/main ↳ Reconcile main with origin/main (rebase or merge its local commits), or specify a different target ``` This is the reporter's suggested direction ("use `origin/<default>` as the merge/rebase target"), minus the network: the already-fetched remote-tracking ref is the measurement base, and `wt merge` still never touches the wire. It also extends the rule the rest of worktrunk already applies — `IntegrationTargets` / the preview panes' comparison base treat the upstream as the truth when the local default lags it; the merge pipeline was the one mutating surface that didn't. Quiet on everything that must keep working: a legitimately-diverged local target with the branch forked from the shared base (the supported offline workflow — existing regression test unchanged), targets with no upstream, orphan branches, and explicit non-branch targets like `wt step squash origin/main`. ## Tests - `test_merge_carries_stale_local_main_through_upstream` — the #3519 topology end-to-end: merge succeeds, the carry is announced, the squash folds only the branch's own commits and sits directly on the `origin/main` tip, and `origin/main` is an ancestor of the merged `main` (real SHAs, no duplication). - `test_step_squash_measures_against_upstream_when_local_main_stale` — the standalone squash folds only the branch's own commits and never moves the target ref (this scenario previously corrupted `main` through a squash-then-merge sequence). - `test_step_rebase_targets_upstream_when_local_main_stale` — a branch that merged `origin/main` in rebases onto the upstream: linearized, real upstream SHAs retained, target ref untouched. - `test_merge_refuses_diverged_target_when_branch_based_on_upstream` — the forced refusal: nothing mutated, branch survives. - `test_merge_removes_branch_when_local_main_diverged_from_upstream` (legitimate divergence, branch from shared base) still passes — no regression. Docs: the merge help page (primary source in `src/cli/mod.rs`) describes the upstream-aware measurement, the carry, and the diverged refusal; generated mirrors and help snapshots regenerated. > _This was written by Claude Code on behalf of Maximilian_ --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Worktrunk Bot
|
3554f4979a |
fix(rebase): surface Ctrl-C during rebase as interrupt, not conflict (#3539)
Surfaced by the nightly code-quality survey; the fix layer was corrected
after review, and the review discussion then drove the `Interrupted`
rendering work (see below).
## Problem
When a `git rebase` child is killed by a signal (SIGINT/SIGTERM) but
leaves the worktree in `REBASING` state, `handle_rebase` classified the
failure by `worktree_state()` alone (now `REBASING`) and returned
`GitError::RebaseConflict`, printing conflict-resolution guidance and a
non-130 exit code instead of a clean interrupt. This violates the
signal-handling policy in `CLAUDE.md`: signal-derived child exits must
be detected via the structured signal channel **before** any other
classification.
The original attempt added an interrupt check to
`classify_rebase_failure`, but it was **inert on the real path**:
`handle_rebase` runs `repo.run_command(["rebase", …])`, which is
`Cmd::run()` capture mode. On failure that returns a `CommandError` (via
`from_failed_output`), never a `WorktrunkError::ChildProcessExited`, and
the interrupt detector only matched `ChildProcessExited`. Worse,
`from_failed_output` stored only `output.status.code()` (which is `None`
for a signal kill) and dropped `output.status.signal()` entirely, so the
signal number wasn't recoverable downstream at all.
A second problem fell out of the review discussion: every interrupt
classification funneled into `AlreadyDisplayed { exit_code: 128 + sig
}`, erasing the signal identity — so a SIGTERM-killed `wt` exited
**silently**. Because wt traps SIGINT/SIGTERM to forward them to
children, the shell never sees wt die and never prints its own
`Terminated` line, so the standard shell convention was suppressed with
nothing in its place. And an interrupt that left the worktree mid-rebase
said nothing about the `REBASING` state it left behind (git ran in
capture mode, so none of its output was ever shown).
## Fix
The capture layer preserves the signal:
- `CommandError` gains a `signal: Option<i32>` field, populated in
`from_failed_output` from `output.status.signal()` on Unix (`None`
elsewhere). A signal-killed child has no exit code, so the display
summary names the signal instead: `git rebase failed (signal 11)`.
- `ErrorExt::interrupt_signal()` (né `interrupt_exit_code()`) walks the
anyhow chain for a `CommandError` carrying SIGINT or SIGTERM, so it
works through `run_command`'s `.context("Failed to execute: git …")`
wrapper.
Only SIGINT/SIGTERM classify as interrupts in capture mode. Capture
children get no signal forwarding or escalation, so a death by any other
signal (SIGSEGV, an OOM SIGKILL) is never wt's own doing, and a silent
exit would discard the captured stderr the user never saw. Those stay on
the visible error path: mid-rebase, the `REBASING` state classifies them
as `RebaseConflict`, whose rendering carries the `--abort` hint;
otherwise `GitError::Other`. Stream mode's `ChildProcessExited` branch
counts any signal: its output already streamed to the terminal, and
user-initiated kills are normalized upstream to the originating
SIGINT/SIGTERM (the `seen_signal` branch in `shell_exec`, the concurrent
runner's originating-signal override).
Interrupt exits are now typed and announced. A new
`WorktrunkError::Interrupted { signal, hint }` replaces
`AlreadyDisplayed { exit_code: 128 + sig }` at every
interrupt-classification site (`handle_command_error`, `for_each`,
`classify_rebase_failure`, `run_custom`'s signal branch). It still exits
`128 + signal`, but renders once, at exit, per shell convention:
- **SIGINT**: silent — the terminal already echoed `^C`, and shells
print nothing for an interrupted job.
- **SIGTERM**: `✗ Terminated` — the line the shell would have printed
had wt not trapped the signal.
- **Any other signal** (reachable from stream mode): `✗ Killed by signal
N`.
`hint` carries an optional recovery line rendered under the message.
`classify_rebase_failure` uses it for the state an interrupt leaves
behind:
```
◎ Rebasing onto main...
✗ Terminated
↳ Rebase onto main left in progress; to abort, run git rebase --abort
```
(For SIGINT the hint stands alone under the user's own `^C`.)
## Reachability caveat
The common terminal Ctrl-C case is subtler than the original description
implied: on paths where wt has not installed its signal handler, a
terminal Ctrl-C is delivered to the whole foreground group and
terminates `wt` itself at 130 before classification runs. The
capture-mode fix is reachable, and correct, when the signal reaches only
the `git` child while `wt` survives (e.g. within `wt merge` after the
handler is installed, a targeted kill, or a supervisor signalling the
child), and it also closes the latent, broader gap where capture-mode
signal deaths were classified without consulting the structured signal
channel at all.
## Tests
- `capture_mode_interrupt_is_not_classified_as_conflict` feeds
`classify_rebase_failure` the real `CommandError`-with-signal shape
(wrapped in the `.context(...)` layer `run_command` adds) and asserts
`Interrupted { signal: 2, hint: Some(…) }` with the `git rebase --abort`
hint, not `RebaseConflict`.
- `capture_mode_crash_signal_stays_a_visible_error` asserts a SIGSEGV
death mid-rebase classifies as `RebaseConflict` and a SIGKILL death
outside `REBASING` as `Other`, never a silent interrupt.
- `interrupt_signal_capture_mode_narrows_to_sigint_sigterm` pins the
capture-mode signal set: 2 and 15 classify, 9 and 11 don't.
- `from_failed_output_preserves_signal_and_interrupt_signal_recovers_it`
pins the capture layer directly: a signal-killed `Output` yields
`signal: Some(2)` / `exit_code: None`, recovered through a
`.context(...)` wrapper.
- `interrupted_renders_by_signal_and_exits_128_plus_signal` pins the
exit-time rendering: silent SIGINT, `✗ Terminated` for SIGTERM, `✗
Killed by signal 9` otherwise, hint placement, and the `128 + signal`
exit codes.
- `test_interrupt_signal` covers the stream-mode channel plus
idempotence (an `Interrupted` error re-checked by an outer loop stays an
interrupt).
- Existing integration tests drive the paths end-to-end:
`test_pre_merge_pipeline_aborts_on_signal_exit` (hook pipeline),
`test_for_each_aborts_on_signal_exit` (worktree loop),
`run_custom_propagates_signal_exit_code` (custom subcommands) — all now
flowing through `Interrupted`.
---------
Co-authored-by: worktrunk-bot <254187624+worktrunk-bot@users.noreply.github.com>
Co-authored-by: Maximilian Roos <m@maxroos.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
|
||
|
Maximilian Roos
|
8f55d15301 |
fix(release): preserve signed Windows zip filename, match checksum format (#3556)
## Summary - The SignPath action's `skip-decompress` defaults to `false`, so it would have extracted the returned zip's contents as loose files into `target/distrib/` instead of saving back a signed `worktrunk-x86_64-pc-windows-msvc.zip`. The checksum step would have silently hashed the still-unsigned zip, and the release would have shipped unsigned Windows binaries with no CI failure to flag it. - `sha256sum` without `-b` omits the `*` binary-mode marker; cargo-dist's own checksums use `<hash> *<filename>` (confirmed against a real release asset). Added `-b` to match. Confirmed via `gh run view` on #3553's own CI run that `build-local-artifacts` is skipped on PRs in this repo, so this code path has never actually executed — this is the first real fix before it runs for real on a tagged release. ## Test plan - [x] `actionlint .github/workflows/release.yaml` — no new warnings (same pre-existing shellcheck style notes as before) - [x] Verified `skip-decompress` behavior against the action's own `action.yml` input spec - [x] Verified checksum format against a real downloaded release asset (`v0.68.0`) > _This was written by Claude Code on behalf of Max_ |
||
|
Maximilian Roos
|
14d4d92532 |
feat(statusline): make the CI and URL segments clickable in Claude Code (#3550)
The statusline suppressed OSC 8 hyperlinks in Claude Code mode, so its CI segment was colored but not clickable and its dev-server URL printed in full. Claude Code renders OSC 8, so both segments now link the way they already do in `wt list`. ``` ~/w/worktrunk.statusline-osc8-hyperlinks ↕|🤖 ↑2 ↓1 ^+93 -24 #3550 :17913 Opus 4.8 └link┘ └link┘ ``` ## Why it was off The gate dated from 2026-01-02, inside Claude Code's OSC 8 regression window — links worked through 2.0.76, broke around 2.1.3, and got a partial IDE-terminal-only fix in 2.1.42 ([anthropics/claude-code#26356](https://github.com/anthropics/claude-code/issues/26356)). The premise was correct when written and has since expired; that issue was auto-closed for inactivity rather than on a fix, so the tracker understates current support. ## Verification PTY-captured the raw byte stream from Claude Code 2.1.218, with `TERM_PROGRAM`/`VSCODE_*` stripped so it exercises the standalone-terminal path that was reported broken. Claude Code doesn't strip or blindly pass through — it parses OSC 8 into its frame model, assigns a hyperlink id, and re-emits canonically (normalizing an ST terminator to BEL): ``` PRE ESC]8;id=1l7bqdh;https://example.com/ST-PROBE BEL STLINKTEXT ESC]8;; BEL MID … ``` It holds in both the normal and alt-screen (`CLAUDE_CODE_NO_FLICKER=1`) render paths, with `FORCE_HYPERLINK` unset. Driving the real `wt` binary through Claude Code end to end yields both links live: ``` LINK: https://github.com/max-sixty/worktrunk/pull/3550 LINK: http://127.0.0.1:17913 ``` Degradation is graceful: a terminal or multiplexer that drops OSC 8 shows the same text, just not clickable (tmux only gained OSC 8 in 3.4; zellij and Alacritty support it). ## Shape of the change With links unconditional for the statusline, the plumbed `include_links` flag had one value, so it collapses into the segment builder. `format_url_cell` likewise takes the link decision from its caller rather than probing the terminal, matching `PrStatus::format_cell` — the statusline's stdout is a pipe, so `supports_hyperlinks` reports false there even though the consumer renders OSC 8. That left `hyperlink_stdout` with no callers, so it goes. `format_cell` keeps its `include_link` parameter: `wt list` passes the terminal probe, and the picker passes `false` because a `--prs` row never reaches the strip path. `format_url_cell` moved next to `estimate_url_width`, which budgets the column against it — the two have to agree on when a cell collapses to `:port` and were in separate files. The URL segment also gets shorter: the URL rides inside the escape sequence, so `http://127.0.0.1:17913` becomes `:17913`, returning 16 columns on a line that budgets by width. ## Safety of the truncation interaction `truncate_visible` ends its cut with `\e[0m`, which resets colour but leaves an OSC 8 link *open* — a severed link would make the rest of the terminal line clickable, and `ansi_cut` really will sever one if reached. It can't be reached, because the two cuts never meet: `fit_to_width` drops whole segments worst-priority-first and stops at one, so character truncation only ever lands on a best-priority survivor — Directory (0), Branch or Model (1) — none of which carry escapes beyond SGR. Every link-bearing segment is strictly worse (CI 5, URL 9), so each is dropped entire first. Reviewing the branch turned up that the numbered comments in `format_statusline_segments` had drifted from `COLUMN_SPECS` — CI was labelled 9 (it is 5) and the URL 8 (it is 9), with branch-diff and upstream also off — and the first version of the test had taken those stale numbers as its specification. The comments are corrected and the test now rests on the invariant above, which doesn't depend on where CI sits. It sweeps widths 1–90 over both links, asserts it spans every drop stage, and pins that the URL goes before CI. A second test pins that the hidden URL costs no visible width (`ansi_strip` drops OSC 8 for both terminators), so priority budgeting isn't inflated. ## Docs The Claude Code statusline page now says the segments are clickable — it's the feature's own page and said nothing about it. The `wt list --help` JSON field description gains the links but stays short: an earlier, longer wording shrank the help table's Field column and wrapped two dozen unrelated rows. ## One judgement call worth flagging `format_statusline_segments` also feeds plain `wt list statusline` (shell prompts) and the JSON `statusline` field. The CI link was already unconditional on both before this change; what's new is that the URL cell renders as a linked `:3000` rather than the full URL, so a consumer that strips OSC 8 sees only `:3000`. The structured `url` / `dev_server.url` field still carries the full URL, and `:3000` still answers "which port", so this reads as the right trade — but it is the one place the collapse to a constant reaches a renderer that isn't Claude Code. 🤖 Generated with [Claude Code](https://claude.com/claude-code) > _This was written by Claude Code on behalf of max_ --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Worktrunk Bot
|
72ae751241 |
docs: correct stale comments (list layout, repository caching spec, zsh probe trace) (#3540)
Stale code comments surfaced by the nightly code-quality survey.
Documentation-only — no behavior change, no test needed.
Three corrections where a comment no longer matched the code it
describes:
- **`src/commands/list/layout.rs`** (two sites) — the Message column's
width bounds are `MIN_MESSAGE = 10` / `MAX_MESSAGE = 100`, but the
allocation pseudo-code comment said "min 20, preferred 50" and the
`calculate_layout_with_width` docstring said "flexible (20-100 chars)".
Both now read 10–100, matching the constants and the authoritative prose
earlier in the same file ("minimum width 10 … expands up to max 100").
- **`src/git/repository/mod.rs`** — the `# Caching` system spec drifted
from the code in three ways: (1) it listed only four process-wide
statics and claimed all were "keyed by canonicalized filesystem path",
but `GIT_COMMON_DIR_CACHE` is keyed by the *raw* discovery path (its own
doc: "Keys are stored as-is"); (2) it omitted two real process-wide
caches of external state, `GIT_CONFIG_PRELOAD` and
`WORKTRUNK_USER_CONFIG_PRELOAD`, both populated by `prewarm` and
consumed by `at()`; (3) the invariants "a cached value … is never
updated within the same command" and "all cache access is lock-free at
the call site" are contradicted by `all_config` being
`OnceCell<RwLock<..>>` — its contents are mutated via `set_config_value`
and read under an explicit lock in `config_last`. The spec now groups
the statics by their actual keying and carves out the `all_config`
exception.
- **`src/shell/utils.rs`** — the zsh compinit-probe trace logged `$ zsh
-ic '…'`, but the invocation is `zsh +m -ic …` (`ZSH_PROBE_FLAGS`). The
`+m` flag is load-bearing (issue #3322 — it prevents the interactive
probe from grabbing wt's controlling terminal), so omitting it from the
trace would mislead anyone copying the logged command to reproduce.
Co-authored-by: worktrunk-bot <254187624+worktrunk-bot@users.noreply.github.com>
Co-authored-by: Maximilian Roos <m@maxroos.com>
|
||
|
Maximilian Roos
|
5f8c301dec |
feat(release): sign Windows binaries via SignPath (#3553)
## Summary - Signs the Windows release zip (`wt.exe` + `git-wt.exe`) via [SignPath](https://signpath.io)'s free OSS code-signing program, using the `test-signing` policy (self-signed test certificate) while the project's Foundation-program application is under review. - Non-blocking (`continue-on-error`) so a signing hiccup can't take down crates.io/homebrew/winget/AUR publishing. - Recomputes the `.sha256` checksum after signing, since the signed zip's bytes differ from the unsigned one. - Uses a dedicated low-privilege `CI builds` SignPath identity (submitter-only), not an admin account. ## Test plan - [x] `actionlint` clean (only pre-existing shellcheck style warnings elsewhere in the file) - [x] Artifact configuration (zip containing `wt.exe` + `git-wt.exe`) validated against SignPath's own XML parser and against the real file layout inside a downloaded `v0.68.0` Windows release zip - [ ] First real Windows build after merge will be the first live signing round-trip through GitHub Actions — watch that release's CI run > _This was written by Claude Code on behalf of Max_ --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Maximilian Roos
|
a3de0b0db6 |
fix: exempt the foreground thread from the command semaphore (#3544)
Accepting a row in the `wt switch` picker could stall for ~10s on a large repo — and indefinitely under sustained background traffic — before the switch began. Every `Cmd::run` acquires the global 32-permit command semaphore, so the accept path's first command queued behind the picker's per-row preview diffs, which on a 38-worktree rust-lang/rust fixture each held a permit for ~14s (trace: Enter at t=4.3s, first switch command spawned at t=14.3s, all of it inside `semaphore().acquire()`). Since permits go to an arbitrary waiter (`Condvar::notify_one`), the foreground can also lose every race while background tasks keep replenishing the queue. The foreground thread — the one that enters `main()` — now bypasses the semaphore in `run` and `pipe_into`. It executes commands one at a time, so it can't contribute to the fan-out the semaphore exists to bound, and it's what the user is waiting on. `stream`/`delayed_stream` already followed this rule; background pool tasks keep the full 32-permit cap. The cap was already approximate (rayon work-stealing can run a capped closure on the calling thread), so no permits are reserved. Verified with a PTY driver against a repo whose `git` shim sleeps 15s on `diff`, with `WORKTRUNK_MAX_CONCURRENT_COMMANDS=2`: accept-to-exit was >100s before (killed) and 0.08s after; a control run of the unfixed binary with an unsaturated cap also exits in 0.08s, isolating the semaphore as the cause. A unit test covers the exemption (initializing thread exempt, spawned threads capped). > _This was written by Claude Code on behalf of max_ --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Maximilian Roos
|
a7c4a7a120 |
refactor(wt-perf): place fixtures under target/wt-perf, not the cache dir (#3547)
## What Move every `wt-perf` on-disk fixture out of the per-user cache dir and under the cargo target dir at `<target>/wt-perf/`, resolved by a renamed `wt_perf_fixture_dir()`: - `setup <config>` fixtures → `<target>/wt-perf/<config>` (was `~/.cache/wt-perf/<config>`). - The rust-lang/rust clone and `prune-real` fixtures → `<target>/wt-perf/bench-repos/` (was `~/.cache/wt-perf/bench-repos/`). - `wt_perf_cache_dir()` → `wt_perf_fixture_dir()`. The target dir is derived from the **running executable's own path** (it lives inside whichever dir cargo built into — `<target>/debug/wt-perf`, `<target>/release/deps/<bench>`), so it honors `CARGO_TARGET_DIR`, a config-file `build.target-dir`, and cargo-llvm-cov's `target/llvm-cov-target/` — none of which a bare `CARGO_TARGET_DIR` env read covers. Falls back to `<workspace>/target` if the binary isn't under a recognizable profile dir. The `etcetera` dependency is dropped. - The `WT_PERF_CACHE_DIR` env override (and the empty-value guard it required) is removed; the benchmarks workflow now caches the deterministic `target/wt-perf/bench-repos` path directly. - In-process throwaway fixtures (`create_repo`) are unchanged — they keep using `tempfile::TempDir`. This reverses the location decision from #3542, which had moved these into `~/.cache/wt-perf`. ## Why `target/` is the conventional home for build/test-generated artifacts — gitignored, reaped by `cargo clean`, and already where criterion writes (`target/criterion`). Keeping every wt-perf fixture there gives one predictable location under the repo that `cargo clean` fully resets. Deriving the target dir from the running binary (rather than assuming `<workspace>/target`) keeps that property intact even when the target dir is relocated. ## Tradeoff (accepted) `target/` is **not** shared across git worktrees (worktrees don't share it) and is wiped by `cargo clean`. So the ~15 GiB `prune-real` rust clone re-clones per worktree and after every `cargo clean` — the cost #3542 avoided by using the cache dir. This is deliberate and documented on `wt_perf_fixture_dir`; it's cheap for the synthetic `setup` fixtures, which rebuild in seconds. ## Testing - `cargo build -p wt-perf --all-targets`, `cargo test -p wt-perf` — clean. - New unit test `target_dir_from_exe_finds_cargo_target` covers the resolution logic (relocated `CARGO_TARGET_DIR`, bench binary under `release/deps/`, cargo-llvm-cov's nested target, closest-profile-wins, and the outside-any-target fallback). - `pre-commit run --all-files` (fmt, clippy, yaml, typos, cargo-lock, custom hooks) — clean. - Smoke-tested end-to-end: `setup branches-2` lands at `<worktree>/target/wt-perf/branches-2` and writes nothing to `~/.cache/`; a copy of the binary run from a fake `<dir>/debug/wt-perf` correctly resolves fixtures to `<dir>/wt-perf/`, proving a relocated target dir is honored. > _This was written by Claude Code on behalf of Maximilian_ --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Maximilian Roos
|
f14fa69c0e |
feat(list): run merge analysis in a read-only object database (#3535)
When the Git object database is read-only, `wt list` and `wt list statusline` redirect their object-writing merge/conflict probes (write-tree, commit-tree, merge-tree --write-tree) into a temporary object database with the real one as a read-only alternate, so the full analysis runs in a managed read-only sandbox. Detection is a one-time writability probe; the writable path is unchanged. Scoped to the two observational list entry points (collect and populate_item); mutating commands keep the persistent database and fail loudly on a read-only store. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Worktrunk Bot
|
dbefb98ed4 |
fix(plugin): add pipefail to WorktreeCreate hook so wt failures surface (#3546)
## Problem
The Claude plugin's `WorktreeCreate` hook
(`plugins/worktrunk/hooks/hooks.json`) pipes the `wt` result straight
into `jq`:
```
bash -c 'name=$(jq -er .name) || exit 1; cd "${CLAUDE_PROJECT_DIR:-.}" || exit 1; bash "$CLAUDE_PLUGIN_ROOT/hooks/wt.sh" switch --create "$name" --no-cd --format=json | jq -er .path'
```
Without `set -o pipefail`, the pipeline's exit status is `jq`'s, not
`wt`'s. On jq 1.6, `jq -er .path` exits **0** on the empty stdout of a
failed `wt`:
```console
$ printf '' | jq -er .path; echo $? # jq 1.6
0
```
So when `wt switch --create` dies (e.g. an existing-branch collision
after the branch/worktree were already created by an earlier partial
run), the hook "succeeds" while printing nothing. Claude Code then
reports the misleading `WorktreeCreate hook failed: hook succeeded but
returned no worktree path` instead of `wt`'s real stderr — as reported
in #3545.
The project's own `skills/wt-switch-create/rationale.md` already
documents the `bash -c 'set -o pipefail; …'` wrapper as the intended
design ("The hooks.json pipefail wrapper"), but the command in
`hooks.json` never actually carried it. This PR brings the code in line
with its own documentation.
## Solution
Prefix the existing `bash -c` command with `set -o pipefail;`. The
wrapper is already `bash -c`, so this is safe — dash rejects `set -o
pipefail` fatally, which is precisely why the `bash -c` wrapper (rather
than the login shell) exists per the rationale. With pipefail, the
pipeline surfaces `wt`'s nonzero exit regardless of jq version.
## Testing
Added a reproduction assertion to `test_plugin_layout_is_consolidated`
(`tests/integration_tests/config_show.rs`) that fails when the
`WorktreeCreate` hook command lacks `set -o pipefail` — it fails on the
pre-fix `hooks.json` and passes after. Also verified the pipeline shape
directly:
```console
$ bash -c 'set -o pipefail; (echo "✗ Branch foo already exists" >&2; exit 1) | jq -er .path'; echo $?
✗ Branch foo already exists
4 # nonzero -> hook correctly fails, wt's stderr shown
$ bash -c 'set -o pipefail; echo "{\"path\":\"/tmp/wt/foo\"}" | jq -er .path'; echo $?
/tmp/wt/foo
0 # success path unchanged
```
The `bash -c '…'` body stays single-quoted, so
`test_claude_hook_commands_parse_in_all_shells` (login-shell parse
check) is unaffected — the outer shells never look inside the quotes.
---
Closes #3545 — automated triage
Co-authored-by: worktrunk-bot <254187624+worktrunk-bot@users.noreply.github.com>
|
||
|
Maximilian Roos
|
e47132966b |
fix(picker): stop burning a core while background collect is pending (#3534)
`wt switch` burned ~100% of one core whenever the picker looked idle but background collect work was still pending: a slow CI fetch, or an LLM branch summary (`[list] summary = true` with a `commit.generation` command). skim's reader polls its item channel with kanal's `recv_timeout(1ms)`, and kanal's timeout wait yields in a loop instead of parking, so an open-but-empty channel spins a full core for as long as any `SkimItemSender` is alive. The handler held its sender for the whole collect, a contract inherited from the skim 0.20 tuikit backend, whose 100ms repaint heartbeat needed a live reader. In skim 5.x, in-place row updates surface via injected `Event::Render` and never touch the channel, so nothing needs the sender past the skeleton batch. The fix consumes the handler's sender at its single send. The channel now closes once the last batch is in (the skeleton, or the `--prs` rows), and skim's reader exits while collect keeps grinding through in-place updates. Measured on the wt-perf picker-test repo, 10s window on an idle picker with a `sleep 30` generation command pending: debug 98% → 1.5% of a core, release 99% → 0.6%. A truly idle picker was already fine (~1%); the burn only ever ran while a sender stayed alive. `/usr/bin/sample` pinned the spin to `skim::reader::collect_items` → `kanal::signal::Signal::wait_timeout` (4027 of 4095 frames). Two bounded windows remain: picker startup until the skeleton batch lands, and `--prs` until the forge call returns. Eliminating those needs an upstream skim fix (the collect loop parking instead of polling); the busy-poll is unchanged through skim 5.4.0. Testing: a new unit test asserts the channel closes at the skeleton send; the picker unit tests and the PTY `switch_picker` suite (which exercise fast-skeleton EOF, preview auto-refresh, `--prs` streaming, and alt-r reload) pass. > _This was written by Claude Code on behalf of max_ Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Maximilian Roos
|
4121dc979c |
refactor(wt-perf): cache fixtures in the platform cache dir, not /tmp or target/ (#3542)
## What Move `wt-perf`'s benchmark/debug fixture repos out of `std::env::temp_dir()` and `target/bench-repos/` into the per-user cache dir, resolved by a new `wt_perf_cache_dir()`: - `$WT_PERF_CACHE_DIR` if set, else `<cache>/wt-perf` via `etcetera::choose_base_strategy().cache_dir()` — `~/.cache/wt-perf` (or `$XDG_CACHE_HOME/wt-perf`) on Linux **and** macOS. This matches worktrunk's own base-dir convention (`src/config/user/path.rs` resolves user config through the same XDG-on-macOS strategy). - `setup <config>` fixtures → `<cache>/<config>` (was `temp_dir()/wt-perf-<config>`). `--path` still overrides. - Real cloned fixtures (`prune-real`, the rust-lang/rust clone) → `<cache>/bench-repos/` (was `target/bench-repos/`). - In-process throwaway fixtures (`create_repo`) are unchanged — they keep using `tempfile::TempDir`. ## Why Both old homes were wrong for a *reused* fixture (these are given stable names, persist between runs, and are referenced from docs and `-C <path>` — that's a cache, not a temp file): - **A fixed name in a shared `/tmp` (Linux)** collides across users: `/tmp` is sticky (`1777`), so a second user's `setup` hits `remove_dir_all().unwrap()` on a dir they don't own → `EPERM` → panic. It's also a predictable-path/TOCTOU hazard, and `systemd-tmpfiles` reaps `/tmp` per-file at 10 days by `max(atime,mtime,ctime)` — on a `noatime` mount an actively-*read* fixture still loses cold `.git/objects/pack/*.pack` mid-use → silent git corruption. - **On macOS**, `temp_dir()` is already `/var/folders/.../T` (per-user, `0700`), so the docs' `/tmp/wt-perf-*` paths were simply wrong there. - **`target/`** is per-worktree (git worktrees don't share it) and wiped by `cargo clean`, so the ~15 GiB rust clone was re-cloned per worktree — worst for the most expensive fixture, in a worktree-heavy workflow. The cache dir is per-user (no collision, no TOCTOU), stable and discoverable (docs/`-C` references still work), shared across worktrees (clone once per machine), and survives `cargo clean` — matching sccache, cargo, rustup, Go, Bazel, and Hugging Face, which all place large reusable caches there rather than in `/tmp`. ## Migration notes - First bench/setup run after this rebuilds the cache under the new location (the old `target/bench-repos/` is no longer read). Existing fixtures can be dropped with `rm -rf target/bench-repos`. - `.github/workflows/benchmarks.yaml` sets `WT_PERF_CACHE_DIR` and caches `$WT_PERF_CACHE_DIR/bench-repos`, so the cached path and the path wt-perf writes stay pinned together (no drift if a runner sets `$XDG_CACHE_HOME`); key unchanged. - Docs (`benches/CLAUDE.md`, `src/commands/CLAUDE.md`) updated to the new paths, noting that `wt-perf setup` prints the exact path. ## Testing - `cargo build --workspace --all-targets`, `cargo clippy --workspace --all-targets --features shell-integration-tests -- -D warnings` — clean. - `cargo test -p wt-perf` — passes. - Smoke-tested default resolution (`~/.cache/wt-perf/…` on macOS), `$WT_PERF_CACHE_DIR` override, and the `prune-real --path` rejection (now names the resolved cache path). > _This was written by Claude Code on behalf of Maximilian_ --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Maximilian Roos
|
0aca156ccd |
fix: use @ before path in -vv startup pointer message (#3543)
The \`-vv\` startup pointer (\`announce_trace_destination\` in \`src/logging.rs\`) printed "Verbose logging to \<dir\>/", using "to" before the path. The codebase convention (see the \`writing-user-outputs\` skill) is \`@\` before paths in user-facing output — #3521 already applied this to the \`-vv\` end-of-run block but left this start-of-run pointer as the one remaining inconsistency. Changes "Verbose logging to \<dir\>/" to "Verbose logging @ \<dir\>/" and updates the matching test assertions/doc comment in \`tests/integration_tests/diagnostic.rs\`. The historical wording quoted in \`CHANGELOG.md\` is left as-is since it documents a past release. > _This was written by Claude Code on behalf of max_ |
||
|
Worktrunk Bot
|
a660d859ee |
refactor: unify subdir preservation for wt step relocate (#3346)
Route `wt step relocate`'s shell `cd` through the shared `resolve_subdir_in_target` helper, so every path-switching command (`switch`, `remove`/`merge`, `relocate`) preserves the user's subdirectory position identically — resolving the follow-up from #3344. Gate `test_relocate_preserves_subdir` to Unix: subdir preservation only fires when the cwd is inside the moving worktree, which is exactly when `git worktree move` (a directory rename) fails on the legacy Windows console — a real limitation, not a test artifact, so the test documents the boundary rather than masking it. |
||
|
Maximilian Roos
|
6a85da8f46 |
refactor(eval): render -v variables through the shared formatter (#3536)
`wt step eval -v` was the last of the four `-v` template-variable listings to hand-roll its own formatting. The hook (foreground + background) and alias sites all render through `format_hook_variables` / `format_alias_variables`; eval instead sorted keys alphabetically, padded, and joined them by hand. #3495 labelled all four block *headers* with their owner, which made eval's differently-formatted *body* stand out. This adds a sibling `format_base_variables` for the bare `base_vars` scope (no hook operation/infrastructure vars, no alias `args`) and routes eval through it, so all four listings are one family. Consequences for the eval listing, now matching the other three: - curated help-table order instead of alphabetical - deprecated aliases (`main_worktree`, `repo_root`, `worktree`, `main_worktree_path`) dropped, as the other sites already omit them - absent optional vars show `(unset)` (e.g. `owner` with no PR context) - variable names render plain, not bold Behavior-only change to the `-v` diagnostic lane; the `eval_verbose` / `eval_format_json_verbose` snapshots capture the new output. > _This was written by Claude Code on behalf of max_ Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Maximilian Roos
|
bf9e603ccd |
build(deps): hold skim at 5.1.0 — 5.3.1 breaks the picker on legacy Windows (#3538)
## Problem skim 5.3.1 breaks the picker on the legacy Windows console. Every picker PTY test on `test (windows)` fails with: ``` ✗ interactive picker failed: Keyboard progressive enhancement not implemented for the legacy Windows API. ``` That is a crossterm keyboard-enhancement error: the picker (via skim 5.3.1) drives keyboard-enhancement handling that the legacy Windows console API doesn't support, crashing the picker at runtime. ~40 `switch_picker` tests fail as a result. ## Evidence it's skim 5.3.1 - **#3526 (bump skim 5.1.0 → 5.3.1) merged with its own `full-tests (windows)` already red** — the regression landed on main unnoticed. - **main at skim 5.1.0 (`0958a365b`) was green on `test (windows)` the same day.** The only relevant change between that green run and the failures is the skim bump. - The failure is a picker runtime crash, unrelated to any picker source change — no `switch_picker` code moved. Since it's on main, it reddens Windows CI for every open PR (e.g. #3346), not just one branch. ## Fix Pin `skim = "=5.1.0"` in `Cargo.toml` — the last Windows-green release — with a comment naming the regression. `Cargo.toml` specified `skim = "5.0"` (a caret range that `5.3.1` satisfies), so #3526 changed **only** the lockfile. A lock-only revert would silently drift back to 5.3.1 on the next `cargo update`, so the hold has to live in the manifest. The lockfile downgrade (skim 5.3.1 → 5.1.0, frizbee 0.11.0 → 0.10.0 and the deps that pulls) follows from the pin. Unpin once skim's keyboard-enhancement path is guarded for the legacy Windows console (upstream fix, or a worktrunk-side guard before enabling enhancement). ## Testing - `cargo run -- hook pre-merge --yes` — full suite green locally (4475 passed, 1 skipped), including the `switch_picker` tests that fail on Windows at 5.3.1. - CI will confirm `test (windows)` returns to green. > _This was written by Claude Code on behalf of Maximilian Roos_ Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
dependabot[bot]
|
89b58e2522 |
chore: bump taiki-e/install-action from 2.83.3 to 2.84.0 (#3529)
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.83.3 to 2.84.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.84.0</h2> <ul> <li> <p>Support <code>d2</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/1944">#1944</a>)</p> </li> <li> <p>Support <code>protoc-gen-connect-openapi</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/1922">#1922</a>, thanks <a href="https://github.com/JasterV"><code>@JasterV</code></a>)</p> </li> <li> <p>Update <code>convco@latest</code> to 0.7.0. (<a href="https://redirect.github.com/taiki-e/install-action/pull/1941">#1941</a>, thanks <a href="https://github.com/graelo"><code>@graelo</code></a>)</p> </li> <li> <p>Update <code>just@latest</code> to 1.57.0.</p> </li> <li> <p>Update <code>cargo-semver-checks@latest</code> to 0.49.0.</p> </li> <li> <p>Update <code>tombi@latest</code> to 1.2.4.</p> </li> <li> <p>Update <code>cosign@latest</code> to 3.1.2.</p> </li> </ul> <h2>2.83.4</h2> <ul> <li> <p>Update <code>vacuum@latest</code> to 0.29.10.</p> </li> <li> <p>Update <code>uv@latest</code> to 0.11.29.</p> </li> <li> <p>Update <code>syft@latest</code> to 1.48.0.</p> </li> <li> <p>Update <code>prek@latest</code> to 0.4.10.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.7.7.</p> </li> <li> <p>Update <code>cargo-shear@latest</code> to 1.13.2.</p> </li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h2>[2.84.0] - 2026-07-20</h2> <ul> <li> <p>Support <code>d2</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/1944">#1944</a>)</p> </li> <li> <p>Support <code>protoc-gen-connect-openapi</code>. (<a href="https://redirect.github.com/taiki-e/install-action/pull/1922">#1922</a>, thanks <a href="https://github.com/JasterV"><code>@JasterV</code></a>)</p> </li> <li> <p>Update <code>convco@latest</code> to 0.7.0. (<a href="https://redirect.github.com/taiki-e/install-action/pull/1941">#1941</a>, thanks <a href="https://github.com/graelo"><code>@graelo</code></a>)</p> </li> <li> <p>Update <code>just@latest</code> to 1.57.0.</p> </li> <li> <p>Update <code>cargo-semver-checks@latest</code> to 0.49.0.</p> </li> <li> <p>Update <code>tombi@latest</code> to 1.2.4.</p> </li> <li> <p>Update <code>cosign@latest</code> to 3.1.2.</p> </li> </ul> <h2>[2.83.4] - 2026-07-17</h2> <ul> <li> <p>Update <code>vacuum@latest</code> to 0.29.10.</p> </li> <li> <p>Update <code>uv@latest</code> to 0.11.29.</p> </li> <li> <p>Update <code>syft@latest</code> to 1.48.0.</p> </li> <li> <p>Update <code>prek@latest</code> to 0.4.10.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.7.7.</p> </li> <li> <p>Update <code>cargo-shear@latest</code> to 1.13.2.</p> </li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/taiki-e/install-action/commit/a6b2e2dcd845ddd7f509ce4f3ed3d922b80cc5d9"><code>a6b2e2d</code></a> Release 2.84.0</li> <li><a href="https://github.com/taiki-e/install-action/commit/fbdd9c50c029b1f2d5667c090563e4a31cc3f43c"><code>fbdd9c5</code></a> Update cargo-neat manifest</li> <li><a href="https://github.com/taiki-e/install-action/commit/424c5f90440984601897d473b7936cc3fd52bda8"><code>424c5f9</code></a> Update changelog</li> <li><a href="https://github.com/taiki-e/install-action/commit/a1fa02c1f9b8ef65d443ad6b3f0b99f5863b6f4f"><code>a1fa02c</code></a> Support <code>protoc-gen-connect-openapi</code> (<a href="https://redirect.github.com/taiki-e/install-action/issues/1922">#1922</a>)</li> <li><a href="https://github.com/taiki-e/install-action/commit/9e22773f98774c41688b7cc39a5f7f7eaa4ca97d"><code>9e22773</code></a> Update DEVELOPMENT.md</li> <li><a href="https://github.com/taiki-e/install-action/commit/8d5009fee2da9de26fee96bb727c2df318ffce42"><code>8d5009f</code></a> Support d2</li> <li><a href="https://github.com/taiki-e/install-action/commit/5193316cc852ca0f37d4819875e939522c4f7c47"><code>5193316</code></a> Update <code>tombi@latest</code> to 1.2.4</li> <li><a href="https://github.com/taiki-e/install-action/commit/4c740c71c8320819d812216022c3ff178e1a3394"><code>4c740c7</code></a> Update <code>tombi@latest</code> to 1.2.3</li> <li><a href="https://github.com/taiki-e/install-action/commit/de240ff26f6e8b33bacd85a1a7c621c92d8d7c70"><code>de240ff</code></a> Update <code>just@latest</code> to 1.57.0</li> <li><a href="https://github.com/taiki-e/install-action/commit/dfca8548668aebabd66da598ea31d87a03819d43"><code>dfca854</code></a> Update <code>cargo-semver-checks@latest</code> to 0.49.0</li> <li>Additional commits viewable in <a href="https://github.com/taiki-e/install-action/compare/v2.83.3...v2.84.0">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
87715c305b |
chore: bump skim from 5.1.0 to 5.3.1 (#3526)
Bumps [skim](https://github.com/skim-rs/skim) from 5.1.0 to 5.3.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/skim-rs/skim/releases">skim's releases</a>.</em></p> <blockquote> <h2>5.3.1 - 2026-07-19</h2> <h2>Release Notes</h2> <h3>🐛 Bug Fixes</h3> <ul> <li>Ignore KeyEventState (<a href="https://redirect.github.com/skim-rs/skim/issues/1127">#1127</a>)</li> </ul> <h2>Install skim 5.3.1</h2> <h3>Install prebuilt binaries via shell script</h3> <pre lang="sh"><code>curl --proto '=https' --tlsv1.2 -LsSf https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-installer.sh | sh </code></pre> <h3>Install prebuilt binaries via powershell script</h3> <pre lang="sh"><code>powershell -ExecutionPolicy Bypass -c "irm https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-installer.ps1 | iex" </code></pre> <h2>Download skim 5.3.1</h2> <table> <thead> <tr> <th>File</th> <th>Platform</th> <th>Checksum</th> </tr> </thead> <tbody> <tr> <td><a href="https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-aarch64-apple-darwin.tar.xz">skim-aarch64-apple-darwin.tar.xz</a></td> <td>Apple Silicon macOS</td> <td><a href="https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-aarch64-apple-darwin.tar.xz.sha256">checksum</a></td> </tr> <tr> <td><a href="https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-x86_64-apple-darwin.tar.xz">skim-x86_64-apple-darwin.tar.xz</a></td> <td>Intel macOS</td> <td><a href="https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-x86_64-apple-darwin.tar.xz.sha256">checksum</a></td> </tr> <tr> <td><a href="https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-x86_64-pc-windows-msvc.zip">skim-x86_64-pc-windows-msvc.zip</a></td> <td>x64 Windows</td> <td><a href="https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-x86_64-pc-windows-msvc.zip.sha256">checksum</a></td> </tr> <tr> <td><a href="https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-x86_64-pc-windows-msvc.msi">skim-x86_64-pc-windows-msvc.msi</a></td> <td>x64 Windows</td> <td><a href="https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-x86_64-pc-windows-msvc.msi.sha256">checksum</a></td> </tr> <tr> <td><a href="https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-aarch64-unknown-linux-gnu.tar.xz">skim-aarch64-unknown-linux-gnu.tar.xz</a></td> <td>ARM64 Linux</td> <td><a href="https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-aarch64-unknown-linux-gnu.tar.xz.sha256">checksum</a></td> </tr> <tr> <td><a href="https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-x86_64-unknown-linux-gnu.tar.xz">skim-x86_64-unknown-linux-gnu.tar.xz</a></td> <td>x64 Linux</td> <td><a href="https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-x86_64-unknown-linux-gnu.tar.xz.sha256">checksum</a></td> </tr> <tr> <td><a href="https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-aarch64-unknown-linux-musl.tar.xz">skim-aarch64-unknown-linux-musl.tar.xz</a></td> <td>ARM64 MUSL Linux</td> <td><a href="https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-aarch64-unknown-linux-musl.tar.xz.sha256">checksum</a></td> </tr> <tr> <td><a href="https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-x86_64-unknown-linux-musl.tar.xz">skim-x86_64-unknown-linux-musl.tar.xz</a></td> <td>x64 MUSL Linux</td> <td><a href="https://github.com/skim-rs/skim/releases/download/v5.3.1/skim-x86_64-unknown-linux-musl.tar.xz.sha256">checksum</a></td> </tr> </tbody> </table> <h2>5.3.0 - 2026-07-19</h2> <h2>Release Notes</h2> <h3>🚀 Features</h3> <ul> <li>Add 'left' and <code>right</code> info display modes (<a href="https://redirect.github.com/skim-rs/skim/issues/1120">#1120</a>)</li> <li>Add <code>--hide-nth</code> to hide fields from display but keep them searchable (<a href="https://redirect.github.com/skim-rs/skim/issues/1122">#1122</a>)</li> <li>Add bind and unbind actions (<a href="https://redirect.github.com/skim-rs/skim/issues/1121">#1121</a>)</li> </ul> <h3>🐛 Bug Fixes</h3> <ul> <li>Kitty keyboard protocol</li> </ul> <h3>🤖 CI</h3> <ul> <li>Add public-api check (<a href="https://redirect.github.com/skim-rs/skim/issues/1124">#1124</a>)</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/skim-rs/skim/blob/master/CHANGELOG.md">skim's changelog</a>.</em></p> <blockquote> <h2>[5.3.1] - 2026-07-19</h2> <h3>🐛 Bug Fixes</h3> <ul> <li>Ignore KeyEventState (<a href="https://redirect.github.com/skim-rs/skim/issues/1127">#1127</a>)</li> </ul> <h2>[5.3.0] - 2026-07-19</h2> <h3>🚀 Features</h3> <ul> <li>Add 'left' and <code>right</code> info display modes (<a href="https://redirect.github.com/skim-rs/skim/issues/1120">#1120</a>)</li> <li>Add <code>--hide-nth</code> to hide fields from display but keep them searchable (<a href="https://redirect.github.com/skim-rs/skim/issues/1122">#1122</a>)</li> <li>Add bind and unbind actions (<a href="https://redirect.github.com/skim-rs/skim/issues/1121">#1121</a>)</li> </ul> <h3>🐛 Bug Fixes</h3> <ul> <li>Kitty keyboard protocol</li> </ul> <h3>🤖 CI</h3> <ul> <li>Add public-api check (<a href="https://redirect.github.com/skim-rs/skim/issues/1124">#1124</a>)</li> </ul> <h2>[5.2.0] - 2026-07-17</h2> <h3>🚀 Features</h3> <ul> <li>Collapsed borders by default and <code>--border-no-collapse</code> flag (<a href="https://redirect.github.com/skim-rs/skim/issues/1117">#1117</a>)</li> <li>Reduce binary size by removing uncommon image formats and color_eyre (<a href="https://redirect.github.com/skim-rs/skim/issues/1118">#1118</a>)</li> </ul> <h2>[5.1.4] - 2026-07-17</h2> <h3>🐛 Bug Fixes</h3> <ul> <li>Preserve input order with --no-sort (<a href="https://redirect.github.com/skim-rs/skim/issues/1115">#1115</a>)</li> </ul> <h3>New Contributors</h3> <ul> <li><a href="https://github.com/juneboku"><code>@juneboku</code></a> made their first contribution in <a href="https://redirect.github.com/skim-rs/skim/pull/1115">#1115</a></li> </ul> <h2>[5.1.3] - 2026-07-16</h2> <h3>🐛 Bug Fixes</h3> <ul> <li>Manually resize the Tui when not in fullscreen mode</li> </ul> <h3>🤖 CI</h3> <ul> <li>Fix fixed viewport resize test in non-interactive env (<a href="https://redirect.github.com/skim-rs/skim/issues/1114">#1114</a>)</li> </ul> <h3>⚙️ Miscellaneous Tasks</h3> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/skim-rs/skim/commit/6dbe37a7fa43f69d906f42b647a5b0221f721bd8"><code>6dbe37a</code></a> release: v5.3.1 (<a href="https://redirect.github.com/skim-rs/skim/issues/1128">#1128</a>)</li> <li><a href="https://github.com/skim-rs/skim/commit/6f94d80973063e3464ef169afbf27034642cde35"><code>6f94d80</code></a> fix: ignore KeyEventState (<a href="https://redirect.github.com/skim-rs/skim/issues/1127">#1127</a>)</li> <li><a href="https://github.com/skim-rs/skim/commit/4d093a42e1ebf94c64d7950e2d4817b30089ae05"><code>4d093a4</code></a> release: v5.3.0 (<a href="https://redirect.github.com/skim-rs/skim/issues/1123">#1123</a>)</li> <li><a href="https://github.com/skim-rs/skim/commit/3c3f26ebc923491031f2728928fd3c18efe46163"><code>3c3f26e</code></a> fix: kitty keyboard protocol</li> <li><a href="https://github.com/skim-rs/skim/commit/ad97bfa7deeee352d743f41ec7cb8bd4b26b4bf6"><code>ad97bfa</code></a> feat: add bind and unbind actions (<a href="https://redirect.github.com/skim-rs/skim/issues/1121">#1121</a>)</li> <li><a href="https://github.com/skim-rs/skim/commit/ff98133bbd4502633a5b01fcadcadccccef437e0"><code>ff98133</code></a> ci: add public-api check (<a href="https://redirect.github.com/skim-rs/skim/issues/1124">#1124</a>)</li> <li><a href="https://github.com/skim-rs/skim/commit/dce26d622a7caec4649b2d379c029a64e4fad66e"><code>dce26d6</code></a> feat: add <code>--hide-nth</code> to hide fields from display but keep them searchable (...</li> <li><a href="https://github.com/skim-rs/skim/commit/55aa7dacd573ccea22f1c3fb655e0a4f91f297a7"><code>55aa7da</code></a> feat: add 'left' and <code>right</code> info display modes (<a href="https://redirect.github.com/skim-rs/skim/issues/1120">#1120</a>)</li> <li><a href="https://github.com/skim-rs/skim/commit/57a7487323b7f63f28a0e142ba38136b79dca11b"><code>57a7487</code></a> release: v5.2.0 (<a href="https://redirect.github.com/skim-rs/skim/issues/1119">#1119</a>)</li> <li><a href="https://github.com/skim-rs/skim/commit/bb6c03f3771766a1830e7c48c3abc26af02de97f"><code>bb6c03f</code></a> feat: reduce binary size by removing uncommon image formats and color_eyre (#...</li> <li>Additional commits viewable in <a href="https://github.com/skim-rs/skim/compare/v5.1.0...v5.3.1">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
076e09a2e4 |
chore: bump tokio from 1.52.3 to 1.53.0 (#3525)
Bumps [tokio](https://github.com/tokio-rs/tokio) from 1.52.3 to 1.53.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/tokio-rs/tokio/releases">tokio's releases</a>.</em></p> <blockquote> <h2>Tokio v1.53.0</h2> <h1>1.53.0 (July 17th, 2026)</h1> <h3>Added</h3> <ul> <li>fs: implement <code>From<OwnedFd></code> and <code>From<OwnedHandle></code> for <code>File</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8266">#8266</a>)</li> <li>metrics: add task schedule latency metric (<a href="https://redirect.github.com/tokio-rs/tokio/issues/7986">#7986</a>)</li> <li>net: add <code>SocketAddr</code> methods to Unix sockets (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8144">#8144</a>)</li> </ul> <h3>Changed</h3> <ul> <li>io: add <code>#[inline]</code> to IO trait impls for in-memory types (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8242">#8242</a>)</li> <li>net: implement UCred::pid on FreeBSD (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8086">#8086</a>)</li> <li>net: support Nuttx target os (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8259">#8259</a>)</li> <li>signal: refactor global variables on Windows (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8231">#8231</a>)</li> <li>sync: <code>mpsc::{Receiver,UnboundedReceiver}</code> now drops waker on drop, even if there are still senders (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8095">#8095</a>)</li> <li>taskdump: support taskdumps on s390x (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8192">#8192</a>)</li> <li>time: add <code>#[track_caller]</code> to <code>timeout_at()</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8077">#8077</a>)</li> <li>time: consolidate mutex locks on spurious poll (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8124">#8124</a>)</li> <li>time: defer waker clone on spurious poll (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8107">#8107</a>)</li> <li>time: move lazy-registration state into <code>Sleep</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8132">#8132</a>)</li> <li>tracing: remove unnecessary span clone (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8126">#8126</a>)</li> </ul> <h3>Fixed</h3> <ul> <li>io: do not treat zero-length reads as EOF in <code>Chain</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8251">#8251</a>)</li> <li>net: use getpeereid for QNX peer credentials (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8270">#8270</a>)</li> <li>runtime: avoid illegal state in <code>FastRand</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8078">#8078</a>)</li> <li>sync: wake mpsc receiver when a queued <code>reserve[_many]</code> returns permits (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8260">#8260</a>)</li> <li>taskdump: skip double wake on <code>Trace::capture</code>/<code>Trace::trace_with</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8043">#8043</a>)</li> <li>time: avoid stack overflow in runtime constructor (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8093">#8093</a>)</li> <li>time (alt timer): ensure timers stay in the same runtime after <code>.reset()</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8169">#8169</a>)</li> </ul> <h3>IO uring (unstable)</h3> <ul> <li>fs: use io-uring for <code>fs::try_exists</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8080">#8080</a>)</li> <li>fs: use io-uring for renaming files (<a href="https://redirect.github.com/tokio-rs/tokio/issues/7800">#7800</a>)</li> <li>rt: flush io-uring CQE in case of CQE overflow (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8277">#8277</a>)</li> </ul> <h3>Documented</h3> <ul> <li>docs: clarify cancel safety wording (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8181">#8181</a>)</li> <li>fs: clarify <code>create_dir_all</code> succeeds if path exists (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8149">#8149</a>)</li> <li>io: add warning about stdout reordering with multiple handles (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8276">#8276</a>)</li> <li>net: document pipe <code>try_read*</code>/<code>try_write*</code> readiness behavior (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8032">#8032</a>)</li> <li>runtime: document interaction with fork() (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8202">#8202</a>)</li> <li>sync: clarify broadcast lagging semantics (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8239">#8239</a>)</li> <li>sync: document memory ordering guarantees for Semaphore (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8119">#8119</a>)</li> <li>task: explain why <code>yield_now</code> defers its waker (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8254">#8254</a>)</li> <li>time: add panic docs to <code>timeout_at()</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8077">#8077</a>)</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/tokio-rs/tokio/commit/be689a35f5ade5a39e507f79d3ec85cdab27806f"><code>be689a3</code></a> chore: prepare Tokio v1.53.0 (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8294">#8294</a>)</li> <li><a href="https://github.com/tokio-rs/tokio/commit/50f76c71ec7203013f7f0cda59deaa9016e93939"><code>50f76c7</code></a> chore: prepare tokio-macros v2.7.1 (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8295">#8295</a>)</li> <li><a href="https://github.com/tokio-rs/tokio/commit/f61fccad3cd598cce743fc511a983364b77af92a"><code>f61fcca</code></a> Merge 'tokio-1.52.4' into 'master' (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8290">#8290</a>)</li> <li><a href="https://github.com/tokio-rs/tokio/commit/efdba5fcf02c4b93d379114df136b994c3b21445"><code>efdba5f</code></a> chore: prepare Tokio v1.52.4 (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8289">#8289</a>)</li> <li><a href="https://github.com/tokio-rs/tokio/commit/b0ba02e75507518baed6718b0c37105e430f3a93"><code>b0ba02e</code></a> Merge 'tokio-1.51.4' into 'tokio-1.52.x' (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8288">#8288</a>)</li> <li><a href="https://github.com/tokio-rs/tokio/commit/7bcd2d343d997a658be5bc165520070c997fefbc"><code>7bcd2d3</code></a> taskdump: remove crate disambiguators from output (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8288">#8288</a>)</li> <li><a href="https://github.com/tokio-rs/tokio/commit/f84b209126a9b0f66dae1025e30e44d217205513"><code>f84b209</code></a> chore: prepare Tokio v1.51.4 (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8286">#8286</a>)</li> <li><a href="https://github.com/tokio-rs/tokio/commit/eacb98e18901fcbe011bfceddbc31853f1bf0c27"><code>eacb98e</code></a> runtime: don't skip the driver when <code>before_park</code> schedules work (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8222">#8222</a>)</li> <li><a href="https://github.com/tokio-rs/tokio/commit/5e16ee00faae5b81a58f70b734577b800e0b203b"><code>5e16ee0</code></a> task: avoid replacing the JoinQueue waker in <code>try_join_next</code> (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8279">#8279</a>)</li> <li><a href="https://github.com/tokio-rs/tokio/commit/88212ab64afd2b2f87deeb073f9eef6aaaad3701"><code>88212ab</code></a> sync: document memory ordering guarantees for Semaphore (<a href="https://redirect.github.com/tokio-rs/tokio/issues/8119">#8119</a>)</li> <li>Additional commits viewable in <a href="https://github.com/tokio-rs/tokio/compare/tokio-1.52.3...tokio-1.53.0">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
0958a365bb |
chore: bump the patch group with 6 updates (#3524)
Bumps the patch group with 6 updates: | Package | From | To | | --- | --- | --- | | [anyhow](https://github.com/dtolnay/anyhow) | `1.0.103` | `1.0.104` | | [clap](https://github.com/clap-rs/clap) | `4.6.1` | `4.6.2` | | [serde](https://github.com/serde-rs/serde) | `1.0.228` | `1.0.229` | | [which](https://github.com/harryfei/which-rs) | `8.0.4` | `8.0.5` | | [regex](https://github.com/rust-lang/regex) | `1.13.0` | `1.13.1` | | [ignore](https://github.com/BurntSushi/ripgrep) | `0.4.28` | `0.4.30` | Updates `anyhow` from 1.0.103 to 1.0.104 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/dtolnay/anyhow/releases">anyhow's releases</a>.</em></p> <blockquote> <h2>1.0.104</h2> <ul> <li>Update <code>syn</code> dev-dependency to version 3</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/dtolnay/anyhow/commit/1dbe1862aae650423e3361fbd20b7d17c5109cc3"><code>1dbe186</code></a> Release 1.0.104</li> <li><a href="https://github.com/dtolnay/anyhow/commit/f6479f8e5e10761d7fecde0970cff363dc644d92"><code>f6479f8</code></a> Update to syn 3</li> <li>See full diff in <a href="https://github.com/dtolnay/anyhow/compare/1.0.103...1.0.104">compare view</a></li> </ul> </details> <br /> Updates `clap` from 4.6.1 to 4.6.2 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/clap-rs/clap/releases">clap's releases</a>.</em></p> <blockquote> <h2>v4.6.2</h2> <h2>[4.6.2] - 2026-07-15</h2> <h3>Fixes</h3> <ul> <li><em>(help)</em> Say <code>alias</code> when there is only one</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/clap-rs/clap/blob/master/CHANGELOG.md">clap's changelog</a>.</em></p> <blockquote> <h2>[4.6.2] - 2026-07-15</h2> <h3>Fixes</h3> <ul> <li><em>(help)</em> Say <code>alias</code> when there is only one</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/clap-rs/clap/commit/0fe0be302726f4253b9bee27eed48438c92917aa"><code>0fe0be3</code></a> chore: Release</li> <li><a href="https://github.com/clap-rs/clap/commit/480af9d045453f4ab96d9bdd4d4b9f5aab3c272f"><code>480af9d</code></a> docs: Update changelog</li> <li><a href="https://github.com/clap-rs/clap/commit/2b3ddd0294a147d1eda917cb303243bcde0c12ee"><code>2b3ddd0</code></a> Merge pull request <a href="https://redirect.github.com/clap-rs/clap/issues/6340">#6340</a> from liskin/fix-completion-escape</li> <li><a href="https://github.com/clap-rs/clap/commit/7ffe7399ff032cc247eb0449cf8fcdfbfe55a4ec"><code>7ffe739</code></a> fix(complete): Do not suggest options after "--"</li> <li><a href="https://github.com/clap-rs/clap/commit/d47fc4f8a5e9fcc16d0cae15b51e6eb1a8ed5832"><code>d47fc4f</code></a> test(complete): Options suggested after escape (<code>--</code>)</li> <li>See full diff in <a href="https://github.com/clap-rs/clap/compare/clap_complete-v4.6.1...clap_complete-v4.6.2">compare view</a></li> </ul> </details> <br /> Updates `serde` from 1.0.228 to 1.0.229 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/serde-rs/serde/releases">serde's releases</a>.</em></p> <blockquote> <h2>v1.0.229</h2> <ul> <li>Update to syn 3</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/serde-rs/serde/commit/7fc3b4c30c94f73a96ebd1553f2b090d928fc3a8"><code>7fc3b4c</code></a> Release 1.0.229</li> <li><a href="https://github.com/serde-rs/serde/commit/6d6e9a11101354ce769a3438a088b6b9305c1863"><code>6d6e9a1</code></a> Merge pull request <a href="https://redirect.github.com/serde-rs/serde/issues/3085">#3085</a> from dtolnay/syn3</li> <li><a href="https://github.com/serde-rs/serde/commit/6dec3b751126c8338cac0fe8085612d695e4ecf3"><code>6dec3b7</code></a> Update to syn 3</li> <li><a href="https://github.com/serde-rs/serde/commit/cfe669241065984177ff63af8b45058e6e9b499d"><code>cfe6692</code></a> Resolve mut_mut pedantic clippy lint</li> <li><a href="https://github.com/serde-rs/serde/commit/1023d077510b4aef36a41ef56fdb7798568a2654"><code>1023d07</code></a> Update actions/upload-artifact@v6 -> v7</li> <li><a href="https://github.com/serde-rs/serde/commit/dd682c2c86aa7629e77c1ccd93212d3729f4c66d"><code>dd682c2</code></a> Update actions/checkout@v6 -> v7</li> <li><a href="https://github.com/serde-rs/serde/commit/5f0f18b9211732f2d82f73b5a43e4f5ff3701251"><code>5f0f18b</code></a> Update ui test suite to nightly-2026-06-01</li> <li><a href="https://github.com/serde-rs/serde/commit/63a1498f0e7be991ffac5939bdd202ca16e9a23f"><code>63a1498</code></a> Regenerate stderr with trybuild normalization fixes</li> <li><a href="https://github.com/serde-rs/serde/commit/fa7da4a93567ed347ad0735c28e439fca688ef26"><code>fa7da4a</code></a> Fix unused_features warning</li> <li><a href="https://github.com/serde-rs/serde/commit/6b1a17851ea3d86a56aa116ca1cbf428f8d5f22d"><code>6b1a178</code></a> Unpin CI miri toolchain</li> <li>Additional commits viewable in <a href="https://github.com/serde-rs/serde/compare/v1.0.228...v1.0.229">compare view</a></li> </ul> </details> <br /> Updates `which` from 8.0.4 to 8.0.5 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/harryfei/which-rs/releases">which's releases</a>.</em></p> <blockquote> <h2>8.0.5</h2> <h2>What's Changed</h2> <ul> <li>Fix absolute path lookup when cwd is disabled by <a href="https://github.com/weifanglab"><code>@weifanglab</code></a> in <a href="https://redirect.github.com/harryfei/which-rs/pull/126">harryfei/which-rs#126</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/weifanglab"><code>@weifanglab</code></a> made their first contribution in <a href="https://redirect.github.com/harryfei/which-rs/pull/126">harryfei/which-rs#126</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/harryfei/which-rs/compare/8.0.4...8.0.5">https://github.com/harryfei/which-rs/compare/8.0.4...8.0.5</a></p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/harryfei/which-rs/blob/master/CHANGELOG.md">which's changelog</a>.</em></p> <blockquote> <h2>8.0.5</h2> <ul> <li>Bug fix: <a href="https://redirect.github.com/harryfei/which-rs/pull/126">#126</a> Do not use current directory for search when provided path is absolute. Thanks <a href="https://github.com/weifanglab"><code>@weifanglab</code></a> for your contribution to which!</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/harryfei/which-rs/commit/7fba0e04d0674bbe8ccf5bfb4f09b1d00925806f"><code>7fba0e0</code></a> bump version number, update CHANGELOG.md</li> <li><a href="https://github.com/harryfei/which-rs/commit/e28a3bf34e41bcc009b990e6c05b4a6e6b01635f"><code>e28a3bf</code></a> Fix absolute path lookup when cwd is disabled (<a href="https://redirect.github.com/harryfei/which-rs/issues/126">#126</a>)</li> <li>See full diff in <a href="https://github.com/harryfei/which-rs/compare/8.0.4...8.0.5">compare view</a></li> </ul> </details> <br /> Updates `regex` from 1.13.0 to 1.13.1 <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/rust-lang/regex/blob/master/CHANGELOG.md">regex's changelog</a>.</em></p> <blockquote> <h1>1.13.1 (2026-07-15)</h1> <p>This is a release that fixes a bug where incorrect regex match offsets could be reported. Note that this doesn't impact whether a match occurs or not, just where it occurs. The match offsets are still valid for slicing, they just may not refer to the correct leftmost-first match. See <a href="https://redirect.github.com/rust-lang/regex/pull/1364">#1364</a> for (many) more details.</p> <p>Bug fixes:</p> <ul> <li><a href="https://redirect.github.com/rust-lang/regex/issues/1354">#1354</a>: Fixes previously unsound reverse suffix and inner optimizations.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/rust-lang/regex/commit/2b527599eb9eea0dcc288c704584f242f26a5c61"><code>2b52759</code></a> 1.13.1, redux</li> <li><a href="https://github.com/rust-lang/regex/commit/40e98238fff903f3e1ec95bbdb487185dd60504a"><code>40e9823</code></a> 1.13.1</li> <li><a href="https://github.com/rust-lang/regex/commit/75fcb962d6ea1c456f6f023c9537a66389413a85"><code>75fcb96</code></a> changelog: 1.13.1</li> <li><a href="https://github.com/rust-lang/regex/commit/64ad0b618e043b791ed5385dd5504a436da1ddae"><code>64ad0b6</code></a> automata: fix bug in reverse suffix/inner optimization</li> <li><a href="https://github.com/rust-lang/regex/commit/fa91c31a4291c9dda6afe19829e6fe2e3bbc2da5"><code>fa91c31</code></a> automata: fix a bug caught by Codex review</li> <li><a href="https://github.com/rust-lang/regex/commit/30390ec3e8889aad830337cdf3a7a01ae195ae73"><code>30390ec</code></a> automata: formatting tweaks</li> <li><a href="https://github.com/rust-lang/regex/commit/821a8eb1ad7860ddc788fe36f495036df63cfc35"><code>821a8eb</code></a> automata: refactor reverse suffix/inner search slightly</li> <li><a href="https://github.com/rust-lang/regex/commit/10afd704d88d00ddfcd10218883a81b3ae5e4831"><code>10afd70</code></a> automata: expose the extracted literals for inner literal extraction</li> <li><a href="https://github.com/rust-lang/regex/commit/8c34f41d3c5a0e16ce17dfb964587cb48625a8d5"><code>8c34f41</code></a> automata: avoid reverse suffix optimization for non-leftmost-first</li> <li><a href="https://github.com/rust-lang/regex/commit/5524f02430d2d118d5c34fde54136d08376de711"><code>5524f02</code></a> test: add regression tests for failed reverse suffix/inner optimizations</li> <li>Additional commits viewable in <a href="https://github.com/rust-lang/regex/compare/1.13.0...1.13.1">compare view</a></li> </ul> </details> <br /> Updates `ignore` from 0.4.28 to 0.4.30 <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/BurntSushi/ripgrep/commit/227381db0ee83dfa4341f1e27ff9617c0f5ad992"><code>227381d</code></a> ignore-0.4.30</li> <li><a href="https://github.com/BurntSushi/ripgrep/commit/b621e65b4fc8a50b55576b07526f21c5d051ad71"><code>b621e65</code></a> ignore: add incremental checking</li> <li><a href="https://github.com/BurntSushi/ripgrep/commit/c55818fd32d68cf742aea67bce86529f198bc985"><code>c55818f</code></a> ignore: more pathutil clean-up</li> <li><a href="https://github.com/BurntSushi/ripgrep/commit/6e527e9202f85a39ab2c4698636710204eb096e0"><code>6e527e9</code></a> ignore: add routine for checking if a path is hidden or not</li> <li><a href="https://github.com/BurntSushi/ripgrep/commit/626b8951acbced7ff710f4e01624a05f219eec38"><code>626b895</code></a> ignore: refactor <code>is_hidden</code></li> <li><a href="https://github.com/BurntSushi/ripgrep/commit/0d7054d8e466d6aa0a6bb6cf121e87225d26df44"><code>0d7054d</code></a> ignore: fix deadlock when visitor panics</li> <li><a href="https://github.com/BurntSushi/ripgrep/commit/576005b322c41174bb21d76122b1411e5d983402"><code>576005b</code></a> grep-searcher-0.1.17</li> <li><a href="https://github.com/BurntSushi/ripgrep/commit/432976d69cdff36d5a0d6845b093cf3f67262b43"><code>432976d</code></a> grep-pcre2-0.1.10</li> <li><a href="https://github.com/BurntSushi/ripgrep/commit/41e0ae702bcbd47b093a33ee73f1497aa4ed20d6"><code>41e0ae7</code></a> grep-matcher-0.1.9</li> <li><a href="https://github.com/BurntSushi/ripgrep/commit/40ffc6e0bd990ba6e56702ed1ec519b7ad96a1e7"><code>40ffc6e</code></a> ignore-0.4.29</li> <li>Additional commits viewable in <a href="https://github.com/BurntSushi/ripgrep/compare/ignore-0.4.28...ignore-0.4.30">compare view</a></li> </ul> </details> <br /> Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
Worktrunk Bot
|
65f02693ae | docs(list): correct main_state priority order in field docstring (#3531) | ||
|
Worktrunk Bot
|
56249f9122 | fix: clear error when new branch name collides with existing branch namespace (#3528) | ||
|
Worktrunk Bot
|
c6eb148e62 | docs(hook): correct pre-switch {{ branch }} resolution note (#3516) | ||
|
Maximilian Roos
|
17add1f6dd |
fix: drop companion log paths from the -vv end-of-run message (#3521)
The `-vv` end-of-run block printed `trace.jsonl` and `subprocess.log` as bare gutter lines under a headline that named only `diagnostic.md` — an unannounced list whose relationship to the headline lived in a code comment, and the third and fourth prints of the same directory in one run. The start-of-run pointer already names the log directory, and the report body already routes readers to the raw companions (`subprocess_log_path` in the template; the profile heading names `trace.jsonl` as its source), so the end block now announces only the one human-facing file: ``` ○ Diagnostics and performance profile saved @ ~/…/.git/wt/logs/diagnostic.md ↳ To report a bug, open an issue (https://github.com/max-sixty/worktrunk/issues/new) and attach a secret gist: gh gist create --web ~/…/diagnostic.md ``` The headline drops "Logs," (the raw logs were precisely what wasn't at that path), and the hint now ends with the copyable gist command, linking the plain `/issues/new` URL instead of the ~150-char prefilled-body URL. > _This was written by Claude Code on behalf of max_ Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
dependabot[bot]
|
013d1cc221 |
chore: bump KSXGitHub/github-actions-deploy-aur from 4.1.3 to 4.2.0 (#3472)
Bumps [KSXGitHub/github-actions-deploy-aur](https://github.com/ksxgithub/github-actions-deploy-aur) from 4.1.3 to 4.2.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/ksxgithub/github-actions-deploy-aur/releases">KSXGitHub/github-actions-deploy-aur's releases</a>.</em></p> <blockquote> <h2>v4.2.0</h2> <p>Add a feature to sync AUR repo (<a href="https://redirect.github.com/KSXGitHub/github-actions-deploy-aur/pull/52">KSXGitHub/github-actions-deploy-aur#52</a>).</p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/KSXGitHub/github-actions-deploy-aur/commit/084b0d9b15415bf9cdb65d44dad1efe37a354050"><code>084b0d9</code></a> style: consistency (<a href="https://redirect.github.com/ksxgithub/github-actions-deploy-aur/issues/55">#55</a>)</li> <li><a href="https://github.com/KSXGitHub/github-actions-deploy-aur/commit/9e2f21095c586521806151200746082d8e02bb90"><code>9e2f210</code></a> fix: force-add <code>PKGBUILD</code> and <code>.SRCINFO</code> in the asset_dir/assets path (<a href="https://redirect.github.com/ksxgithub/github-actions-deploy-aur/issues/53">#53</a>)</li> <li><a href="https://github.com/KSXGitHub/github-actions-deploy-aur/commit/7acb32fe8c43848121eee16dd39d8294ec2bf25b"><code>7acb32f</code></a> feat: full asset sync (<a href="https://redirect.github.com/ksxgithub/github-actions-deploy-aur/issues/52">#52</a>)</li> <li>See full diff in <a href="https://github.com/ksxgithub/github-actions-deploy-aur/compare/v4.1.3...v4.2.0">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
dependabot[bot]
|
99704db62f |
chore: bump taiki-e/install-action from 2.83.2 to 2.83.3 (#3497)
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.83.2 to 2.83.3. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.83.3</h2> <ul> <li> <p>Update <code>release-plz@latest</code> to 0.3.160.</p> </li> <li> <p>Update <code>prek@latest</code> to 0.4.9.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.7.6.</p> </li> <li> <p>Update <code>dprint@latest</code> to 0.55.2.</p> </li> <li> <p>Update <code>cargo-dinghy@latest</code> to 0.8.5.</p> </li> <li> <p>Update <code>cargo-binstall@latest</code> to 1.21.0.</p> </li> <li> <p>Update <code>biome@latest</code> to 2.5.4.</p> </li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h2>[2.83.3] - 2026-07-16</h2> <ul> <li> <p>Update <code>release-plz@latest</code> to 0.3.160.</p> </li> <li> <p>Update <code>prek@latest</code> to 0.4.9.</p> </li> <li> <p>Update <code>mise@latest</code> to 2026.7.6.</p> </li> <li> <p>Update <code>dprint@latest</code> to 0.55.2.</p> </li> <li> <p>Update <code>cargo-dinghy@latest</code> to 0.8.5.</p> </li> <li> <p>Update <code>cargo-binstall@latest</code> to 1.21.0.</p> </li> <li> <p>Update <code>biome@latest</code> to 2.5.4.</p> </li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/taiki-e/install-action/commit/ed67fa35ac944f3a9b33f12c4dd43b6f31a47e20"><code>ed67fa3</code></a> Release 2.83.3</li> <li><a href="https://github.com/taiki-e/install-action/commit/618fa5589cc587c869ec39ae0606a6cf6ef03c0b"><code>618fa55</code></a> Update prek manifest</li> <li><a href="https://github.com/taiki-e/install-action/commit/47579092c792f14738b668ee240d199bcad0d8e2"><code>4757909</code></a> Update zizmor manifest</li> <li><a href="https://github.com/taiki-e/install-action/commit/f1fa00538cc2e7231cb60e4d47c24597e0c387b7"><code>f1fa005</code></a> Update uv manifest</li> <li><a href="https://github.com/taiki-e/install-action/commit/aa8dc906017e56077bc125256c4d9301b1cde72a"><code>aa8dc90</code></a> Update <code>release-plz@latest</code> to 0.3.160</li> <li><a href="https://github.com/taiki-e/install-action/commit/b9654978ff643e657a453245addf012127caa2c5"><code>b965497</code></a> Update <code>prek@latest</code> to 0.4.9</li> <li><a href="https://github.com/taiki-e/install-action/commit/7aab3a9c373d60a23a5b89c212174c0baa6a0fa0"><code>7aab3a9</code></a> Update <code>mise@latest</code> to 2026.7.6</li> <li><a href="https://github.com/taiki-e/install-action/commit/bfee8d1ca4d6f82a5c3f7151f046e75e6c202ff5"><code>bfee8d1</code></a> Update kingfisher manifest</li> <li><a href="https://github.com/taiki-e/install-action/commit/b65771b2e228b44f33eb596fbf78979075cd8aa7"><code>b65771b</code></a> Update <code>dprint@latest</code> to 0.55.2</li> <li><a href="https://github.com/taiki-e/install-action/commit/20468927b3c1d5f14e6c4c1379ced0c6cc1ed103"><code>2046892</code></a> Update <code>cargo-dinghy@latest</code> to 0.8.5</li> <li>Additional commits viewable in <a href="https://github.com/taiki-e/install-action/compare/v2.83.2...v2.83.3">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
Worktrunk Bot
|
5967df2dfc | chore(ci): weekly renovation 2026-07-19 (#3518) | ||
|
Worktrunk Bot
|
b1042cfc20 | docs(picker): correct format_log_output hash-marker note (#3515) | ||
|
Worktrunk Bot
|
86daf56dfe | fix(diagnostic): avoid panic slicing config/log at non-UTF-8 boundaries (#3514) | ||
|
Worktrunk Bot
|
d44d68797a | docs(extending): add workz to custom-subcommand examples (#3513) | ||
|
Worktrunk Bot
|
cda5080195 | test(list): exercise real wide-char branch names in width test (#3511) | ||
|
Rene Leonhardt
|
79be81a4bb | fix(merge): Accept merge-shaped fast-forward histories (#3509) |