fix(muse#52): reflog human text output uses long_id, not short_id
_fmt_entry rendered commit IDs as sha256:<12-hex> in human text output, inconsistent with every other Muse command (all of which use the full sha256:<64-hex> canonical form) and a genuine prefix-collision risk for IDs copied out of reflog output. The JSON output path was already correct.
- _fmt_entry now uses long_id for both new_id and old_id; the 'initial' sentinel for a null old_id is unchanged. - Removed the unused short: int = 12 parameter and the now-dead short_id import. - Fixed the docstring's false claim that short IDs were used 'for consistency with all other Muse commands' -- the opposite was true. - Fixed the module-level format spec (<new_sha12> -> <new_sha256>). - Updated tests/test_reflog_supercharge.py's TestTextFormatShortId class (renamed TestTextFormatLongId) -- it explicitly asserted the buggy short-ID behavior as correct; now asserts the fixed long-ID behavior.
TDD: tests/test_cmd_reflog_long_ids.py, 7 tests (LI_01-LI_06), red-first, all green. Full reflog regression sweep: 278 passed across 11 test files.
Semantic Changes
28 symbols
0 comments
muse hub commit comment sha256:97740e0836930191f9f6b756651581010478b51744537383727954f45e8c3cd2 --body "your comment"
No comments yet. Be the first to start the discussion.