Should I submit my Git/worktree workflow improvements to upstream?

[kossnocorp]

Hey!

I developed a few Git/worktrees workflow improvements and am wondering if you want to see those in upstream. If so, I can polish the code and send PR(s).

The improvements:

• Worktrunk integration
• Use branch names for worktrees
• Branch prefix setting

Worktrunk Integration.

It adds a setting to use Worktrunk (wt CLI) to manage worktrees.

How Worktrunk Integration Works

1. It adds a new "Worktrees" section with a "Worktrunk" setting that probes the wt binary similar to git.

2. When enabled (off by default), instead of following the regular worktrees workflow and creating a worktree in ~/.t3, it uses wt switch --create --json <branch-name> which uses Worktrunk settings and hooks.

3. The default Worktrunk configuration would create a worktree in ../<project-name>.<worktree-name>/ which also matches VS Code worktrees feature behavior.

The commit: kossnocorp@5862f9a

Use Branch Names for Worktrees

It makes T3 Code use the generated branch names for worktrees instead of random ids, so <path>/t3code-deb4bb4e/ -> <path>/t3code-add-branch-prefix-setting.

It synergizes with Worktrunk integration and produces clean paths and easily recognizable names in the OS windows selection (e.g., GNOME dashboard), and recent projects list, etc.:

The commit: kossnocorp@1b344d1

Branch Prefix Setting

It adds a setting that allows changing the default t3code/ prefix.

For my workflow I use an empty string "", so worktrees have clean paths, e.g., ~/code/t3code.expand-new-thread-prompt instead of ~/code/t3code.t3code-expand-new-thread-prompt.

The commit: kossnocorp@25aca0f

[drawmeanelephant]

Of course you should.

[mikenrafter]

#6719 is related.

[lunaynx]

Yes please, this sounds like an amazing idea. I'm quite picky about my worktree workflow. Currently I just use wt + Claude/Codex CLI but having this would definitely push me more to try out T3 Code.

[RobertoGongora]

I would appreciate the default branch name setting option, defaulting to t3code feels like leaving the "Co-authored by Claude" messages. I like t3code but I don't necessarily love broadcasting what tools I'm using.

[jpsirois]

At my day job we have a weird requirement where branch name should not be more then 30 chars, while I'm really not a fan, I would really like an option to configure that as a branch name policy

[julianpoma]

The sole reason why I have not adopted t3 as a daily driver is this.

[Arzaroth]

I've implemented the Worktrunk part of this on current main. It adds an opt-in setting under Settings → Worktrees, Worktree manager, with Git and Worktrunk as the choices. With Worktrunk selected, T3 creates and removes worktrees with wt, so wt's location and hooks apply. T3's automatic cleanup and its rebuild of missing worktrees also cover those worktrees.

The branch is https://github.com/Arzaroth/t3code/tree/feature/wt-worktrees.

#11266 hosts the design question of a Worktrunk-specific setting versus generic workspace providers, so I've posted the details there.

[cosmicdreams]

I have to give a big +1 on this feature and @Arzaroth 's design. I also have struggled with T3's specific use of worktrees.

This covers a layout I use, worktrees as siblings of a main checkout (repo/worktrees/main, repo/worktrees/<ticket>), with one user-level wt setting for every repo:

worktree-path = "{{ repo_path }}/../{{ branch | replace('feature/', '') | sanitize }}"

From the CLI, t3 thread start --worktree main --branch feature/ABC-900 ran the agent in repo/worktrees/ABC-900 on feature/ABC-900.

From the UI, a "New worktree" thread whose message started "ABC-902: fix the typo…" landed in repo/worktrees/t3-b3574694 on t3/fix-readme-typo-1. The composer has no branch-name field, and the later rename changes only the branch. kossnocorp's "use branch names for worktrees" commit, which names the branch before creating the worktree, would close that.

Deleting the thread in the UI removed the worktree; the t3-worktree.<path>.manager git-config entry stayed.