fix: muse hub repo create defaults to initialize=false (musehub#220)
Part 2 of musehub#220: even once the server-side bug is fixed (companion musehub commit -- create_repo's seeded commit was structurally invalid, no snapshot_id/MusehubSnapshot row), the CLI's own default was still wrong. `muse hub repo create` is used almost exclusively in the opposite workflow from the API's own initialize=True default: real local content already exists and is about to be pushed. A seeded placeholder commit there is pure friction, not a feature -- every first push this season had to reach for --force because of it.
Replaced --no-init (default initialize=True) with --initialize (default initialize=False, opt-in for the rare case someone wants a browsable-before-first-push repo). Kept the API's own default unchanged -- other callers (e.g. a future web UI wizard) may genuinely want initialize=True's behavior once it's fixed server-side.
Updated the two existing tests whose names/bodies encoded the old default (test_initialize_true_by_default -> test_initialize_false_by_default, test_create_no_init_flag -> test_create_initialize_flag) plus all docstring/help-text references to --no-init.
Verified live end-to-end against a local MuseHub instance (see the companion musehub commit for the full repro): `muse hub repo create` (no flags) + `muse push local main` succeeded with no --force needed; `muse hub repo create --initialize` + `muse clone` on the resulting empty repo succeeded cleanly.
Regression: 523 passed in test_cmd_hub_hardening.py.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Semantic Changes
8 symbols
Files Changed
~2
1259 in snapshot
0 comments
muse hub commit comment sha256:b98f06613c0d1d470ed7a9ddc97c148926beccecc60f3e86ab274d4fc23b8b98 --body "your comment"
No comments yet. Be the first to start the discussion.