Migrating from `git gtr`: config footguns

Open
  • Is something wrong?
#3,454 11 comments 1 reaction 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
32/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
git, rust
Domain
cli, tooling

Research direction

Start by reading project_config_path() in src/git/repository/config.rs and comparing its relative-path behavior with the default config path described in the issue. Then inspect how wt config state currently handles values. Done means the project has decided whether to adopt the proposed worktrunk.config.* Git config convention and defined its scope and compatibility approach.

Written by the indexing model from the issue text.

Description

Howdy @max-sixty 👋 — Really enjoying using wt. Your effort is much appreciated 🙏 I was on git gtr for about a year before I switched. Now I couldn't imagine going back because wt list makes juggling a dozen worktrees obvious

The pain point has been not having git gtr's config management — git gtr config:

# writes to .git/config — local to this checkout, private, always-trusted
git gtr config add gtr.hook.postCreate "pnpm install && ./hack/oneoff.sh"

# --global writes to ~/.gitconfig — every repo
git gtr config add gtr.hook.postCreate "pnpm install" --global

# committed .gtrconfig — shared with the team, gated behind `git gtr trust`
git gtr config set gtr.copy.include "**/.env.example"

Prior art: reading the tea leaves

When it comes to configs in general, I am with you on being "very keen to keep them simple". That said this issue continues to come up, which suggests other folks are stubbing their toes like I am trying to do what git gtr makes obvious and clean

git gtr is a fairly popular runner (~1.7k stars, brew installs ~5% userbase). I cite it specifically because I noticed that it hasn't been in the conversation. The config model it uses at once robust/flexible and simple

  • #650 ("Better config/hook ergonomics…") — Also resolved because .git/config is shared across worktrees
  • #1077 ("Support local config"): Closed. With the approach below the need for repo-specific
    file proposed goes away while still being shared across all worktrees
  • #2818 ("Untracked wt.toml config files no longer work"): Closed. With the approach below the need for the uncommitted file goes away while still being shared across all worktrees
  • #2856: Fixed via #2873, which is a fair amount of plumbing to keep track of. Using the approach git gtr leverages makes per-worktree config files obsolete which reduces complexity a fair amount 🎉

Why not existing solutions

There are two existing solutions here:

  • ~/.config/worktrunk/config.toml: per-project config overrides
    • Issue: #596
    • PR: #749
  • .config/wt.toml: per-repo or per-worktree config overrides
    • Recent fix: #2873

I thought about using both but adding [projects."github.com/owner/repo"] in my user config every time I use worktrunk with a new git repo is not pragmatic for my workflow

I am currently using .config/wt.toml and I nerd sniped myself here when trying to change that default path to wt.config.toml (not possible: .config/wt.toml is hard coded today).

RFC: worktrunk.config. prefixed values in git config

# local to this checkout — .git/config, uncommitted, private
wt config state worktrunk.config.hook.post-start "./hack/vendor.sh && pnpm install"

# global — ~/.gitconfig
wt config state worktrunk.config.hook.post-start "pnpm install" --global

Why I think this still honors our shared value on being "very keen to keep them configs simple":

  • No new config source. It's git's existing surface, not a new file format. Precedence is git's own, which everyone already understands: .git/config (local) over ~/.gitconfig (global).
  • Trust stays coherent. Local config is authored by me in my own checkout — always trusted, same as today's user config. Committed hooks keep the approval prompt.
  • worktrunk.config.* prefix separates "state" from "config" we prefer the existing wt config state command with a conventionally prefixed key worktrunk.config.* to avoid introducing ambiguity for existing wt config state managed values
  • includeIf for free. The [projectsMatching "hasconfig:…"] ask in #650 is literally git's conditional includes — you inherit it at zero cost.
  • Fixes a footgun. WORKTRUNK_PROJECT_CONFIG_PATH resolves relative to CWD
    • NOT the worktree root — project_config_path() in src/git/repository/config.rs returns PathBuf::from(path) verbatim, while the default branch does root.join(".config").join("wt.toml"). A relative override silently no-ops from a subdirectory. Reading via git config is worktree-aware by construction.

imho this makes the .config/wt.toml and [projects.*] plumbing redundant (which strictly speaking simplifies the codebase around config management a fair amount), but that also requires releasing breaking changes, which are can often take on lives of their own.

Will 100% submit a PR for this if you think it's worth exploring. Thoughts?

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.