Raised while building Episode 01 ("The Whole Workflow") demo material.
Not a bug — the current output is correct, just less informative than
it could be for exactly the two-branch-comparison use case the command
is for.
Current real behavior:
muse diff feature/friendlier feature/farewell
M hello.py
├─ added function farewell L6–7
└─ function greet (implementation changed) L1–2
1 modified file, 1 added, 1 modified symbols
Both ops are shown flat, with no indication of which side of the
comparison introduced which change. In this exact scenario that's
recoverable by reasoning (only feature/farewell could have added
farewell, since it doesn't exist on feature/friendlier at all;
only feature/friendlier touched greet's body) — but that reasoning
gets harder fast with more than two changes, or when both branches
touch the same symbol differently (which would currently show as a
single "modified" entry with no way to tell it's actually a
three-way-mergeable divergence rather than one side's edit).
The ask: for the two-ref form specifically (muse diff <refA> <refB>, as opposed to working-tree-vs-HEAD diff), consider labeling
each symbol-level op with which side it came from — something like:
M hello.py
├─ added function farewell L6–7 (feature/farewell)
└─ function greet (implementation changed) (feature/friendlier)
This is presentational/informational only — it wouldn't change
--json's existing symbols shape in a breaking way, could likely be
an additive field (e.g. "origin": "feature/farewell" per symbol
entry) rather than a schema change.
Why it's useful: this is exactly the moment muse merge --dry-run
users are trying to build intuition for before a real merge --- "which
branch is responsible for which change" is the natural next question
after seeing that two branches touched the same file without
conflicting, and today the tool doesn't answer it, only the ops
themselves.
Not urgent — deferred per usual until after the season wraps. Feels
like a nice-to-have UX improvement, not something blocking anything.
Raised while building Episode 01 ("The Whole Workflow") demo material. Not a bug — the current output is correct, just less informative than it could be for exactly the two-branch-comparison use case the command is for.
Current real behavior:
Both ops are shown flat, with no indication of which side of the comparison introduced which change. In this exact scenario that's recoverable by reasoning (only
feature/farewellcould have addedfarewell, since it doesn't exist onfeature/friendlierat all; onlyfeature/friendliertouchedgreet's body) — but that reasoning gets harder fast with more than two changes, or when both branches touch the same symbol differently (which would currently show as a single "modified" entry with no way to tell it's actually a three-way-mergeable divergence rather than one side's edit).The ask: for the two-ref form specifically (
muse diff <refA> <refB>, as opposed to working-tree-vs-HEAD diff), consider labeling each symbol-level op with which side it came from — something like:This is presentational/informational only — it wouldn't change
--json's existingsymbolsshape in a breaking way, could likely be an additive field (e.g."origin": "feature/farewell"per symbol entry) rather than a schema change.Why it's useful: this is exactly the moment
muse merge --dry-runusers are trying to build intuition for before a real merge --- "which branch is responsible for which change" is the natural next question after seeing that two branches touched the same file without conflicting, and today the tool doesn't answer it, only the ops themselves.Not urgent — deferred per usual until after the season wraps. Feels like a nice-to-have UX improvement, not something blocking anything.