feat(josh-sync): rename --subfolder now git mv's the actual directory

Previously --subfolder only repointed .josh-sync.yml, leaving the working
tree out of sync with the new path until a later filter-change
reconciliation happened to catch it. Now validates the old subfolder
exists and is tracked by git (proof it's actually managed by josh-sync)
and the new one doesn't already exist, then git mv's it — staged, not
committed, alongside the config edit. Idempotent on resume. Bumps to
v2.4.0.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TNXgcFWVgSh3wkQS55cCX6
This commit is contained in:
2026-07-17 11:58:55 +01:00
co-authored by Claude Sonnet 5
parent be4aef588d
commit e5403e4300
6 changed files with 217 additions and 9 deletions
+7
View File
@@ -1,5 +1,12 @@
# Changelog
## 2.4.0
### Features
- **`josh-sync rename --subfolder` now moves the actual directory.** Previously a `--subfolder` rename only repointed `.josh-sync.yml` (and the `josh_filter`/state), leaving the monorepo working tree out of sync with the new path until a later sync's filter-change reconciliation happened to catch it. It now `git mv`s the subfolder in the working tree as part of the rename (staged, not committed — reviewed alongside the config edit like everything else `rename` writes). Idempotent: a re-run after a partial move (new path exists, old one doesn't) detects it and skips straight to updating state.
- **New validation before any subfolder move**: the old subfolder must exist and be tracked by git (`git ls-files` under that path non-empty — proof it's actually managed by josh-sync, not a stale/misconfigured path), and the new subfolder must not already exist. Neither check is bypassable with `--force`.
## 2.3.1
### Fixes