feat: CLI writes git local config during context setup#40
Conversation
There was a problem hiding this comment.
@bezhermoso Heads up — this PR builds on your work in #23 (local-context-first config via git local config).
PR #23 added the CLI read path for wt.* git config keys so the CLI could detect plugin-created contexts. This PR adds the corresponding write path so that wt context add also writes those same 7 wt.* keys to .git/config, not just to .conf files.
This bridges two gaps:
- CLI read ↔ write parity: the CLI can now both read and produce
wt.*git config keys - CLI ↔ plugin parity: contexts created from either surface now produce identical config artifacts (both
.conf+ git local config), so the plugin's primary detection path (GitConfigHelper.readConfig) works for CLI-created contexts too — no need to fall back to.conffile matching
The key names and semantics match GitConfigHelper.writeConfig exactly. Would appreciate your review since you added the cli config detection layer.
| fi | ||
| info "Writing git local config..." | ||
| git -C "$repo_root" config --local wt.enabled true | ||
| git -C "$repo_root" config --local wt.contextName "$context_name" |
There was a problem hiding this comment.
Curious: what does the repo's awareness of which context it belongs to achieve?
There was a problem hiding this comment.
currently It's more for the UI of the plugin.
I also had the idea of having a repo provisioned by multiple context, so that even within the repo you can have multiple symlinks that are active, but that would require more metadata either in the repo's git config or .git/wt/ of each worktree
guodong-sq
force-pushed
the
parity/6-cli-git-config-writes
branch
from
7d476cd to
535e1dd
Compare
Make wt context add write wt.* keys to .git/config, matching what the plugin's GitConfigHelper.writeConfig does. This eliminates the asymmetry where CLI-created contexts lack the higher-priority git config source. Changes: - Add _wt_write_git_config helper to lib/wt-context-setup that writes all 7 wt.* keys matching plugin's GitConfigHelper.writeConfig exactly - Call it after .conf file write in wt_setup_context - Handle empty metadataPatterns with --unset (matching plugin behavior) - Gracefully skip when no .git exists - Update stale comment in GitConfigHelper.kt that incorrectly stated only the plugin writes git config Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
guodong-sq
force-pushed
the
parity/6-cli-git-config-writes
branch
from
535e1dd to
674aafe
Compare
2 participants
Summary
Bridges the gap between CLI and plugin config writing, completing the work started in #23 which introduced CLI reading of
wt.*git local config keys.PR #23 added
wt_read_git_configso the CLI could detect contexts created by the plugin viawt.*keys in.git/config. However, the CLI's ownwt context addonly wrote.conffiles — it never wrotewt.*keys back. This meant:.conf+ git config (plugin writes both).conf(CLI never wrote git config)The plugin's
ContextService.detectContext()checks git config first (primary, faster path) and falls back to.conffiles. CLI-created contexts always hit the fallback path.This PR closes that asymmetry so both CLI and plugin produce identical config artifacts:
_wt_write_git_confighelper tolib/wt-context-setupthat writes all 7wt.*keys matching the plugin'sGitConfigHelper.writeConfigexactly.conffile write inwt_setup_contextmetadataPatternswith--unset(matching plugin behavior).gitexistsGitConfigHelper.ktthat incorrectly stated only the plugin writes git configTest plan
cd test && bats unit/wt-context-setup.bats(6 new tests)wt_read_git_configreads back all written keys.gitcase warns and returns 0lib/wt-context-setup🤖 Generated with Claude Code