fix: Query changed-files now respects --head and avoids local status mixing

[nicolasgere]

Summary

Fixes #2511.

When --base and --head were both passed to moon query changed-files, the --head revision was silently ignored and the command fell back to a one-argument git diff <base> (base → working tree). It also unconditionally merged git status output, so commits after --head and local uncommitted changes appeared as false positives.

Changes

• git_client.rs: Pass head_revision into exec_diff instead of an empty string, so git diff runs with two explicit revisions.
• changed_files.rs: Only merge local git status changes when head is not explicitly set. When the user asks for a diff between two SHAs, we return a pure tree-to-tree diff.

Verification

• moon query changed-files --base <X> --head <Y> now returns the same files as git diff --name-only <X> <Y>.
• Open-ended queries (no --head) still include local working tree changes, preserving existing behavior.

[Copilot]

Pull request overview

Fixes moon query changed-files so --head is respected and tree-to-tree diffs don’t accidentally fall back to base → working-tree comparisons (and associated false positives).

Changes:

• Forward head_revision into GitTree::exec_diff so git diff runs with 2 explicit revisions when provided.
• Gate merging of local git status results to avoid mixing local/index changes into explicit revision comparisons (intended behavior).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
crates/vcs/src/git/git_client.rs	Ensures get_changed_files_between_revisions(base, head) actually diffs base..head instead of base..worktree.
crates/app/src/queries/changed_files.rs	Adjusts when local index/working-tree changes are merged into query results.

[Copilot]

The new condition if head_value.is_none() || options.local still merges vcs.get_changed_files() when --head is explicitly set in the common local-default case (since options.local defaults to !ci). This means moon query changed-files --base X --head Y can still include working-tree/index changes as false positives unless --remote is also passed, which contradicts the intent expressed by the surrounding comment and PR description (pure tree-to-tree diff when comparing two explicit revisions). Consider gating the local merge solely on head_value.is_none() (or otherwise ensure explicit --head never consults git status).

[Copilot]

There are existing CLI tests for query changed-files, but none assert the key behavior being changed here: when both --base and --head are provided, results should match a pure tree-to-tree diff and must not include local working tree/index changes. Adding an integration test that creates two commits/branches and verifies --base <X> --head <Y> output (and that local edits after Y are excluded) would prevent regressions for #2511.

Suggested change

	// Only include local changes when not explicitly comparing two revisions
	if head_value.is_none() || options.local {
	// Only include local changes when not explicitly comparing two revisions.
	// When both base and head are provided, this must remain a pure tree-to-tree diff
	// and must not include working tree or index changes.
	if head_value.is_none() && base_value.is_none() {

[Copilot]

This fixes the immediate bug by forwarding head_revision into exec_diff, but there doesn't appear to be coverage for the two-explicit-revision path (get_changed_files_between_revisions(base, head) with a non-empty head). Adding a VCS-level test that compares 2 commits/branches (and asserts the result matches git diff base head) would help ensure --head is not silently ignored again.

[milesj]

I can't remember why it is this way.

But I think head_revision should only be used if merge_base_revision is the same as the original base_revision, otherwise the new merge base diverges.