`wt step` confusion

Open
#4,728 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
28/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
cli

Research direction

Start by reading the CLI command definitions and tests for wt step and the existing verbs mentioned in the proposal. Map each subcommand and alias to its current registration and identify the affected help text and tests. The proposal leaves several destination commands open; agree on the command layout before changing it, then update the tests to cover the new command paths and confirm only merge stages remain under wt step.

Written by the indexing model from the issue text.

Description

I'm new to worktrunk and keep tripping over wt step. Its help says "Run individual operations", and the examples describe the manual merge workflow (commit → squash → rebase → push). Those four subcommands fit that description well. The other eight don't: they're unrelated tools that seem to have ended up under step because they had no other home.

Here's what wt step contains today (v0.81.0), grouped by what each command actually does:

Kind Subcommands
Parts of the wt merge pipeline commit, squash, rebase, push
Looking at a branch diff
Moving files between worktrees copy-ignored
Templates and scripting eval, for-each
Maintaining worktrees in bulk prune, relocate, promote
Supervising processes tether

wt step <alias> also runs a configured alias, even though wt <alias> already works at the top level.

Rational

  • The name doesn't help you find things. If I want to remove merged worktrees, I'd look under wt remove, not wt step prune. If I want to see a branch's changes, wt step diff isn't
    where I'd look either.
  • It hides how the merge pipeline works. wt step would be a clear way to explain wt merge (run its stages one at a time) if those four commands weren't mixed in with eight others.

Proposal

Make wt step mean only "the stages of wt merge", and move everything else out:

  1. Keep commit, squash, rebase, push under wt step.
  2. Move commands to an existing verb where one fits. For example, prune could become wt remove --merged.
  3. Move commands to top-level or new verb for other commands (relocate, promote, for-each, eval, tether, copy-ignored, and possibly diff). For example wt foreach mirrors git submodule foreach nicely.
  4. Stop accepting aliases under wt step, since they already work as wt <alias>.
Dominant language
Rust
Stars
8.8k
Forks
315
Avg merge
1d 6h
Merged PRs (30d)
204

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from max-sixty/worktrunk

All issues in max-sixty/worktrunk

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.